Describe the bug
When units = "imperial" is set, the Yr (met.no) provider does not convert values to imperial. The met.no API only returns SI/metric data (no unit query params exist for it), so conversion must happen client-side. Instead, rustormy keeps the raw metric numbers but relabels them as imperial (e.g. 33.5°F, 3.9 mph). The OpenMeteo provider handles the same config correctly because it offloads conversion to the API via query params.
To Reproduce
Steps to reproduce the behavior:
Config params: units = "imperial"
Run arguments: once with provider = "yr", once with provider = "openmeteo" for the same location
Compare output — Yr shows raw metric values with °F/mph labels
Expected behavior
Yr output should match OpenMeteo (within rounding). With imperial units, met.no's 33.5°C should display as ~92.3°F and 3.9 m/s as ~8.7 mph.
Screenshots
Output comparison (same location, same config):
text
OpenMeteo (correct)
Temperature: 91.2°F (feels like 106.3°F)
Wind: 6.9 mph ↑
Humidity: 73% (dew point 81.3°F)
Yr / met.no (raw metric, mislabeled)
Temperature: 33.5°F (feels like 37.0°F)
Wind: 3.9 mph ↑
Humidity: 60% (dew point 21.3°F)
Debug logs confirm met.no returns SI units:
text
"units":{"air_temperature":"celsius","wind_speed":"m/s","precipitation_amount":"mm"}
"air_temperature":33.5,"wind_speed":3.9
while OpenMeteo's request sets units server-side:
text
...&temperature_unit=fahrenheit&wind_speed_unit=mph&precipitation_unit=inch
OS: Gentoo
Rustormy version: 0.5.1
Additional context
Affected conversions for the Yr provider: temperature, apparent/feels-like temperature, dew point (°C→°F), wind speed (m/s→mph), and likely precipitation (mm→inch). Worth checking whether the same client-side conversion gap affects metric-mode users of API-converting providers in reverse.
Describe the bug
When units = "imperial" is set, the Yr (met.no) provider does not convert values to imperial. The met.no API only returns SI/metric data (no unit query params exist for it), so conversion must happen client-side. Instead, rustormy keeps the raw metric numbers but relabels them as imperial (e.g. 33.5°F, 3.9 mph). The OpenMeteo provider handles the same config correctly because it offloads conversion to the API via query params.
To Reproduce
Steps to reproduce the behavior:
Config params: units = "imperial"
Run arguments: once with provider = "yr", once with provider = "openmeteo" for the same location
Compare output — Yr shows raw metric values with °F/mph labels
Expected behavior
Yr output should match OpenMeteo (within rounding). With imperial units, met.no's 33.5°C should display as ~92.3°F and 3.9 m/s as ~8.7 mph.
Screenshots
Output comparison (same location, same config):
text
OpenMeteo (correct)
Temperature: 91.2°F (feels like 106.3°F)
Wind: 6.9 mph ↑
Humidity: 73% (dew point 81.3°F)
Yr / met.no (raw metric, mislabeled)
Temperature: 33.5°F (feels like 37.0°F)
Wind: 3.9 mph ↑
Humidity: 60% (dew point 21.3°F)
Debug logs confirm met.no returns SI units:
text
"units":{"air_temperature":"celsius","wind_speed":"m/s","precipitation_amount":"mm"}
"air_temperature":33.5,"wind_speed":3.9
while OpenMeteo's request sets units server-side:
text
...&temperature_unit=fahrenheit&wind_speed_unit=mph&precipitation_unit=inch
OS: Gentoo
Rustormy version: 0.5.1
Additional context
Affected conversions for the Yr provider: temperature, apparent/feels-like temperature, dew point (°C→°F), wind speed (m/s→mph), and likely precipitation (mm→inch). Worth checking whether the same client-side conversion gap affects metric-mode users of API-converting providers in reverse.