[GH-ISSUE #146] Weather forecast showing yesterday as day 1 in some time zones #2834

New Issue

sascha_hemi · 2026-03-20T22:05:01+01:00

sascha_hemi commented

2026-03-20 22:05:01 +01:00

Originally created by @svenove on GitHub (Oct 15, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/146

Describe the bug
Depending on the setting used as time zone, the forecast shows yesterday as day 1.

To Reproduce
Steps to reproduce the behavior:

Go to 'Settings'
Set time zone to 'London'
Set a tag to show weather forecast
See error

Expected behavior
The forecast should show the weather from today, not yesterday

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Might also affect “current weather”, but I haven’t tested that.

I might try to fix this myself and add a PR.

Originally created by @svenove on GitHub (Oct 15, 2023). Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/146 **Describe the bug** Depending on the setting used as time zone, the forecast shows yesterday as day 1. **To Reproduce** Steps to reproduce the behavior: 1. Go to 'Settings' 2. Set time zone to 'London' 3. Set a tag to show weather forecast 4. See error **Expected behavior** The forecast should show the weather from today, not yesterday **Screenshots** If applicable, add screenshots to help explain your problem. **Additional context** Might also affect “current weather”, but I haven’t tested that. I might try to fix this myself and add a PR.

sascha_hemi added the bug label 2026-03-20 22:05:01 +01:00

sascha_hemi closed this issue

2026-03-20 22:05:01 +01:00

sascha_hemi commented

2026-03-20 22:05:01 +01:00

@nlimper commented on GitHub (Oct 15, 2023):

Thanks for the report. It would be great if you try to fix is yourself.

Note, that working with time zones can be complex:
Imagine, you are somehwere (place A) at timezone GMT+8. You set the timezone in the AP config.
You enter a weather forecast for a place (B) that is located at timezone GMT-10.
Now, when it's Monday at your location A, it's still Sunday in the place B. The question is, should the forecast display the time in timezone of place A or place B? imho, it should be place B, so here, it's valid that the forecast starts with Sunday, although at your location A it's already Monday.

Maybe that's not the cause of the issue you're describing (I didn't look into it), but if you're fixing it, take good care about the correct timezones.

@nlimper commented on GitHub (Oct 15, 2023): Thanks for the report. It would be great if you try to fix is yourself. Note, that working with time zones can be complex: Imagine, you are somehwere (place A) at timezone GMT+8. You set the timezone in the AP config. You enter a weather forecast for a place (B) that is located at timezone GMT-10. Now, when it's Monday at your location A, it's still Sunday in the place B. The question is, should the forecast display the time in timezone of place A or place B? imho, it should be place B, so here, it's valid that the forecast starts with Sunday, although at your location A it's already Monday. Maybe that's not the cause of the issue you're describing (I didn't look into it), but if you're fixing it, take good care about the correct timezones.

sascha_hemi commented

2026-03-20 22:05:02 +01:00

@svenove commented on GitHub (Oct 15, 2023):

In that scenario the forecast should change from Sunday to Monday at 2am. But even now, at 9pm on Sunday, it shows the forecast for Saturday.

I need to refresh my coding skills (6 years since I last was writing code for NodeMCUs/8266). So this is a nice challenge. 😊

@svenove commented on GitHub (Oct 15, 2023): In that scenario the forecast should change from Sunday to Monday at 2am. But even now, at 9pm on Sunday, it shows the forecast for Saturday. I need to refresh my coding skills (6 years since I last was writing code for NodeMCUs/8266). So this is a nice challenge. 😊

sascha_hemi commented

2026-03-20 22:05:02 +01:00

@svenove commented on GitHub (Oct 15, 2023):

I belive I figured it out, but wanted to get an expert opinion on it... ;)

This was the URL called for my forecast:
https://api.open-meteo.com/v1/forecast?latitude=63.43049&longitude=10.39506&daily=weathercode,temperature_2m_max,temperature_2m_min,precipitation_sum,windspeed_10m_max,winddirection_10m_dominant&windspeed_unit=ms&timeformat=unixtime&timezone=Europe/Oslo

This was in the returned JSON:
"daily": {
"time": [
1697320800,

1697320800 = GMT Sat Oct 14 2023 22:00:00 GMT+0000

From open-meteo.com docs:
"If format unixtime is selected, all time values are returned in UNIX epoch time in seconds. Please note that all timestamp are in GMT+0! For daily values with unix timestamps, please apply utc_offset_seconds again to get the correct date."

The returned JSON also includes:
"utc_offset_seconds": 7200,

And by adding 7200 to 1697320800 we get:
GMT Sun Oct 15 2023 00:00:00 GMT+0000

So I belive this change in contentmanager.cpp (line 819-821) would fix the problem:
const unsigned long utc_offset = doc["utc_offset_seconds"];
for (uint8_t dag = 0; dag < column[0]; dag++) {
const time_t weatherday = (daily["time"][dag].as<time_t>() + utc_offset);

I'm not home to test it for 1-2 days, but does this look like a possible solution?

@svenove commented on GitHub (Oct 15, 2023): I belive I figured it out, but wanted to get an expert opinion on it... ;) This was the URL called for my forecast: https://api.open-meteo.com/v1/forecast?latitude=63.43049&longitude=10.39506&daily=weathercode,temperature_2m_max,temperature_2m_min,precipitation_sum,windspeed_10m_max,winddirection_10m_dominant&windspeed_unit=ms&timeformat=unixtime&timezone=Europe/Oslo This was in the returned JSON: "daily": { "time": [ 1697320800, 1697320800 = GMT **Sat** Oct 14 2023 **22:00:00** GMT+0000 From open-meteo.com docs: "If format unixtime is selected, all time values are returned in UNIX epoch time in seconds. Please note that all timestamp are in GMT+0! **For daily values with unix timestamps, please apply utc_offset_seconds again to get the correct date**." The returned JSON also includes: "utc_offset_seconds": 7200, And by adding 7200 to 1697320800 we get: GMT **Sun** Oct 15 2023 00:00:00 GMT+0000 So I belive this change in contentmanager.cpp (line 819-821) would fix the problem: `const unsigned long utc_offset = doc["utc_offset_seconds"];` ` for (uint8_t dag = 0; dag < column[0]; dag++) {` ` const time_t weatherday = (daily["time"][dag].as<time_t>() + utc_offset);` I'm not home to test it for 1-2 days, but does this look like a possible solution?

sascha_hemi commented

2026-03-20 22:05:02 +01:00

@nlimper commented on GitHub (Oct 16, 2023):

That sounds like it could very well be the solution :-) Take your time to test it, and I'm looking forward to your PR.

@nlimper commented on GitHub (Oct 16, 2023): That sounds like it could very well be the solution :-) Take your time to test it, and I'm looking forward to your PR.

sascha_hemi commented

2026-03-20 22:05:02 +01:00

@nlimper commented on GitHub (Oct 19, 2023):

thanks for fixing!

@nlimper commented on GitHub (Oct 19, 2023): thanks for fixing!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/OpenEPaperLink#2834