Forecast.Solar: Daylight saving seems to be implemented incorrectly

[CommanderRedYT]

The problem

Since 31. of March, we have summertime in europe. Since this date, the forecast seems to be off about an hour, which is exactly how the clocks changed. Before the date, the graphs aligned.

What version of Home Assistant Core has the issue?

core-2024.4.0

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Container

Integration causing the issue

forecast_solar

Link to integration documentation on our website

https://www.home-assistant.io/integrations/forecast_solar

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[home-assistant[bot]]

Hey there @klaasnicolaas, @frenck, mind taking a look at this issue as it has been labeled with an integration (forecast_solar) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of forecast_solar can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign forecast_solar Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

forecast_solar documentation forecast_solar source _{^{(message by IssueLinks)}}

[klaasnicolaas]

The question is where this problem arises and whether this is an Home Assistant integration related issue or whether it already arises with the API server of forecast.solar itself. The data we request is in the ISO8601 format and displays the local time.

./Klaas

[klaasnicolaas]

Could you check what system time you have set in your Home Assistant container?

./Klaas

[CommanderRedYT]

I ran this inside the docker container:

$ date +"%Z %z"
CEST +0200

[Mariusthvdb]

seeing the same on HA OS... so probably nothing to do with install method?

[klaasnicolaas]

In the past, issues have been made by people who ran either Home Assistant container or supervised. A possible solution might be to retrieve the data using UTC time. My graph of today:

[suprimex]

I am voting up, because of the same issue.

[coderjohnjohn]

Same issue here, on a HA Green device with factory installation, updated to latest. Am in GMT+13 Auckland timezone, which is +1hour for southern hemisphere winter, so the forecast is showing a 12pm peak production instead of an 11am peak. I'm guessing the system just doesn't have the info to know what the daylight saving time offset is?

[kchiem]

I have this issue as well, running HAOS. However in my case, forecast data seems to be an hour behind.

[core-ssh ~]$ date +"%Z %z"
PDT -0700

[iRonin]

Not sure if it's related but in my case there is a discrepancy between the dashed line and sensor.power_highest_peak_time_today. I'm in GMT-4 without daylight saving time (Antigua). The dashed line seems okay showing the peak around noon but the sensor tells it's at 11am:

(this is at 10:36am)

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[CommanderRedYT]

This issue still occurs for me with latest version of homeassistant

[lukshan13]

Can confirm this issue exists. Would a configurable offset work in settings?

[CommanderRedYT]

I think knowing the offset via the location and timezone and date would be better. Automatic daylight saving etc.

[klaasnicolaas]

I wonder to what extent this is really an integration issue or rather something for the frontend repository for specifically this energy dashboard graph.

./Klaas

[lukshan13]

I think knowing the offset via the location and timezone and date would be better. Automatic daylight saving etc.

Oh, 100%, but i remember viewing a Tom Scott video on the night mares of managing TimeZones. A configurable offSet value, that we can modify would be great, we can write our own automation to manage it too for automatic daylight savings. It's not the ideal case, but it would work.

I wonder to what extent this is really an integration issue or rather something for the frontend repository for specifically this energy dashboard graph.

./Klaas

There's quite a bit of posts on reddit about this issue. A lot of people are seeing the graphs to be offset by +- hour or two. Don't get me wrong, it's amazing work, but it would amazing if this feature would be enabled to let us change the offset a bit

[klaasnicolaas]

Setting an offset is not a neat way to solve this and I don't see us building something like that into the integration anytime soon. Besides, the integration does nothing more than retrieve data and throw it directly to the frontend of the energy dashboard to process it further.

There's quite a bit of posts on reddit about this issue.

This problem has been there for as long as the integration and the energy dashboard exist (2021), there have been multiple frontend issues created about this but often automatically closed due to inactivity.

Ultimately, I think that this issue also belongs better in the frontend repositoy than here in core. It goes wrong in the energy dashboard itself or in what the API gives us in combination with the processing of this in the python package.

./Klaas

[lukshan13]

That's fair enough. I suspect that it's not going to be solved anytime soon on the front end. I know it's not a 'neat' solution but it would be a solution that could relatively quickly be implemented. What are your thoughts on if I or another developer create a pull request with the offset feature?

[klaasnicolaas]

Be my guest to work on it, bit curious how you think to solve this in code. Ultimately the review process will determine whether it will actually be merged.

Another thing I was thinking about is to no longer retrieve the data in ISO8601 (local time) but as UTC.

./Klaas

[lukshan13]

Sure man, I'll take a look into it when I get some time. I'll take a look at both approaches. Is there a way to run the core integration code without needing to pass in an instance of HA? Never worked on an integration before

[ximex]

I would recommend to use UTC everywhere (API, Storage,...) except what geht displayed to the User, this should bei the local timezone including summer/winter time

[isaac-the-newt]

Hi there, I monitor three sites in Australia all within a 20km radius of each other. Since this time zone moved to daylight savings in October, I have observed errors in the current and predicted solar forecast graphs for each site. While I'm not sure the root cause of this issue is related to the one that was the reason for opening this original issue thread, I add these observations that may help with resolving the problem. In the attached annotated screen captures taken from each site you can see there is a null (zero) point on each graph directly at 11am. This is for the current day's forecast graphs as well as a sample from one site of tomorrow's forecast solar production. As I expect this line graph is a created using some polynomial line fitting function, it looks like the data points for 11am are zero consistently. As it happens, these site are all in the state of New South Wales on the east coast of Australia (about 2 hours north of Sydney). This time zone is UTC+10 during "standard" time but becomes UTC+11 during daylight savings time. The similarity in the "11" hour offset to UTC may be a coincidence but the graph is consistently showing a null point every day for all sites at exactly 11am. All Home Assistants are running on Raspberry Pi 4 units with identical (and current, up to date) versions of core and related integration software. Core 2024.12.2 Supervisor 2024.11.4 Operating System 14.0 Frontend 20241127.7 Thanks for creating such a powerful and reliable software system.

[CommanderRedYT]

@klaasnicolaas

Another thing I was thinking about is to no longer retrieve the data in ISO8601 (local time) but as UTC.

But isn't the idea behind ISO8601 that you have the offset encoded so you can always Calculate UTC if needed?

In JavaScript world it's the ideal format because it's both readable, has offset information and does not have floating point problems.

[CommanderRedYT]

Haven't had time to look at frontend code but there should probably be some function that uses the time format setting from the user settings and formats the time. There probably also is some function to get the UTC offset so we might be fine by just adding this value to the points x coordinate.

I believe as long as we are 100% sure that backend gives the correct time I can provide a PR for frontend, but I would like someone to confirm that.

[SupermotoJerry]

Hi there, I monitor three sites in Australia all within a 20km radius of each other. Since this time zone moved to daylight savings in October, I have observed errors in the current and predicted solar forecast graphs for each site. While I'm not sure the root cause of this issue is related to the one that was the reason for opening this original issue thread, I add these observations that may help with resolving the problem. In the attached annotated screen captures taken from each site you can see there is a null (zero) point on each graph directly at 11am. This is for the current day's forecast graphs as well as a sample from one site of tomorrow's forecast solar production. As I expect this line graph is a created using some polynomial line fitting function, it looks like the data points for 11am are zero consistently. As it happens, these site are all in the state of New South Wales on the east coast of Australia (about 2 hours north of Sydney). This time zone is UTC+10 during "standard" time but becomes UTC+11 during daylight savings time. The similarity in the "11" hour offset to UTC may be a coincidence but the graph is consistently showing a null point every day for all sites at exactly 11am. All Home Assistants are running on Raspberry Pi 4 units with identical (and current, up to date) versions of core and related integration software. Core 2024.12.2 Supervisor 2024.11.4 Operating System 14.0 Frontend 20241127.7 Thanks for creating such a powerful and reliable software system.

I have the very same issue.

I just posted about it here:

https://github.com/home-assistant/core/issues/133325

[klaasnicolaas]

@CommanderRedYT The integration now always retrieves in UTC by default (since some releases ago), it is up to the frontend to always show the correct value/graph for the time zone you are in.

./Klaas

[SupermotoJerry]

Hi there, I monitor three sites in Australia all within a 20km radius of each other. Since this time zone moved to daylight savings in October, I have observed errors in the current and predicted solar forecast graphs for each site. While I'm not sure the root cause of this issue is related to the one that was the reason for opening this original issue thread, I add these observations that may help with resolving the problem. In the attached annotated screen captures taken from each site you can see there is a null (zero) point on each graph directly at 11am. This is for the current day's forecast graphs as well as a sample from one site of tomorrow's forecast solar production. As I expect this line graph is a created using some polynomial line fitting function, it looks like the data points for 11am are zero consistently. As it happens, these site are all in the state of New South Wales on the east coast of Australia (about 2 hours north of Sydney). This time zone is UTC+10 during "standard" time but becomes UTC+11 during daylight savings time. The similarity in the "11" hour offset to UTC may be a coincidence but the graph is consistently showing a null point every day for all sites at exactly 11am. All Home Assistants are running on Raspberry Pi 4 units with identical (and current, up to date) versions of core and related integration software. Core 2024.12.2 Supervisor 2024.11.4 Operating System 14.0 Frontend 20241127.7 Thanks for creating such a powerful and reliable software system.

@isaac-the-newt

This has now been resolved. @klaasnicolaas suggested I post about it on the forecast.solar discord, which I did and it turned out to be an API bug. This has now been resolved. See the discord messages below:

https://discord.com/channels/898084609017925633/1034916719682146304/1318232299791319110

[isaac-the-newt]

Hi there,

Thanks for the update.

The API edit has fixed the null point dip but introduced another issue with attenuated forecasts.

I have posted this on the forecast. Solar Discord as suggested.

regards,

Greg Belcher

From: SupermotoJerry @.> Sent: Tuesday, 17 December 2024 12:21 To: home-assistant/core @.> Cc: isaac-the-newt @.>; Mention @.> Subject: Re: [home-assistant/core] Forecast.Solar: Daylight saving seems to be implemented incorrectly (Issue #115214)

Hi there, I monitor three sites in Australia all within a 20km radius of each other. Since this time zone moved to daylight savings in October, I have observed errors in the current and predicted solar forecast graphs for each site. While I'm not sure the root cause of this issue is related to the one that was the reason for opening this original issue thread, I add these observations that may help with resolving the problem. In the attached annotated screen captures taken from each site you can see there is a null (zero) point on each graph directly at 11am. This is for the current day's forecast graphs as well as a sample from one site of tomorrow's forecast solar production. As I expect this line graph is a created using some polynomial line fitting function, it looks like the data points for 11am are zero consistently. As it happens, these site are all in the state of New South Wales on the east coast of Australia (about 2 hours north of Sydney). This time zone is UTC+10 during "standard" time but becomes UTC+11 during daylight savings time. The similarity in the "11" hour offset to UTC may be a coincidence but the graph is consistently showing a null point every day for all sites at exactly 11am. All Home Assistants are running on Raspberry Pi 4 units with identical (and current, up to date) versions of core and related integration software. Core 2024.12.2 Supervisor 2024.11.4 Operating System 14.0 Frontend 20241127.7 Thanks for creating such a powerful and reliable software system.

@isaac-the-newt https://github.com/isaac-the-newt

This has now been resolved. @klaasnicolaas https://github.com/klaasnicolaas suggested I post about it on the forecast.solar discord, which I did and it turned out to be an API bug. This has now been resolved. See the discord messages below:

https://discord.com/channels/898084609017925633/1034916719682146304/1318232299791319110

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/115214#issuecomment-2547298502 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AWY7QEZ6L4UYPWDLB2IYRK32F537BAVCNFSM6AAAAABF43JAUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBXGI4TQNJQGI . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AWY7QEZQXGEVQSPDUQ5FHQD2F537BA5CNFSM6AAAAABF43JAUKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTUX2SYMM.gif Message ID: @.*** @.***> >

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[isaac-the-newt]

Thank you for your support. I reconfirm this issue has long since been resolved as outlined above. Please find attached my upwards pointing thumb and you may proceed to close this case. 👍