getify
commented
8 months ago As an example, I was in CDT (still on DST), and I was looking at a location like Miami or Boston (ET), on 11/5 (DST-end day). And I flipped on the setting for using my own local timezone.
What the hourly forecast hour labels for 11/5 should have said in that case would be (25 labels because of the repeated label -- "12am" in CDT, "1am" in EDT):
"11pm" (which would have been from 11/4) "12am" "12am" "2am" "3am" ... "11pm"
Instead, (I think) it incorrectly displayed:
"11pm" "12am" "1am" "1am" "1am" "3am" ... "11pm"
I did significant work to fix some DST bugs related to forecast data (daily -- sunrise/sunset, as well as hourly). The root of the problem is the weather API doesn't return forecast data with DST awareness. The API server itself switches to DST whenever according to its physical/logical location, but doesn't respect the DST status of any locations it's providing future forecast data for. This causes various off-by-one-hours.
Though most of the bugs were fixed, unfortunately, some DST bugs still remain. I think they're related to the specific DST-change day, not the subsequent days.
In particular, it seems like if you have selected the config to display/format times in your own timezone (instead of remote timezone), AND you look at a location in a different timezone from your own, AND it's the DST-change day... the logic currently used for fixing the hour timezone labels is bad. THAT logic is here:
https://github.com/getify/demo-app-weatheround/blob/887b8f18c63a738343faac291a76cfa1f0dcce7a/web/src/hooks/useGetWeather.js#L562-L696
That logic makes the assumption for DST-change days that it needs to slide the hourly labels by 1 (upward or downward). But the amount it needs to slide (and pull from the previous or next days) is likely not
1but needs to include the delta between your local timezone offset and the target timezone offset.Likely to be very tricky logic here. Ugh.