Core: Darksky platform - incorrect day labels on Lovelace Weather Card (and others)

[wixoff]

Home Assistant release with the issue:
0.91.2 and earlier

Last working Home Assistant release (if known):
None known

Operating environment (Hass.io/Docker/Windows/etc.):
Home Assistant on Fedora Linux x86-64 running in Docker. Has functioned well for more than a year.

Component/platform:
platform:darksky, weather card in lovelace

Description of problem:
As shown in the attached screenshots, the darksky platform is set to daily mode. However, the day labels in the official weather lovelace card (and in the custom weather-card-chart) are simply misaligned - one day off.

I'm writing this report on Wednesday, and the card starts with a weather forecast for Tuesday. The rain shown to appear on Thursday and Friday is actually, per Dark Sky, expected to arrive on Friday and Saturday. Similarly, the temperature forecasts are also a day off.

Because multiple Lovelace cards are affected, I suspect this may be an issue with the darksky platform itself.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

weather:
  - platform: darksky
    api_key: [arglebargle]
    mode: daily

Traceback (if applicable):
N/A - no log entries or errors.

Additional information:

[github-actions[bot]]

Hey there @fabaff, mind taking a look at this issue as its been labeled with a integration (darksky) you are listed as a codeowner for? Thanks!

[cgtobi]

Can you please check if your system time is correct?

[wixoff]

@cgtobi Not a bad idea. The system time on the host is just fine, but I'll check whether TZ in the container has things messed up. When I last checked through, it was Wednesday (or Thursday) everywhere in the world and the weather card still showed Tuesday.

[wixoff]

No luck. The time (via the bash date command) is exactly the same both inside and outside the container. And it's Wednesday.

[cgtobi]

Since I don't use docker I don't know how to reproduce what behaviour. Here it works fine but that does help you. ;-)

[cgtobi]

Have you tried different browsers? What OS is your client on?

[aplsms]

i've tested on MacOs Mojave 10.14.4 + latest IOS (browser and homeassistant.app) issue present on safari

[aplsms]

looks like the problem is not on javascript code on the card:

     computeDate(data) {
         const date = new Date(); // orig: const date = new Date(data);
         return date.toLocaleDateString(this.hass.language, { weekday: "short" });
      }

return correct DOW.

can you check what is data on safari and chrome?

[rrosson]

I am following this issue as well. macOS 10.14.4 using Safari has this issue. When running chrome on same OS the card is displayed correctly. iOS 12.2 using the Home Assistant application has the display issue. Chrome on Windows 10 works properly. MS Edge on Windows 10 will not render the card.

Hope this helps.

[cgtobi]

Have you tried http://<your-hass-instance>:8123/states?latest?

Have you configured the frontend javascript version?

frontend:
  javascript_version: latest

[aplsms]

yes, i did test it with "javascript_version: latest" -- the same result

[BartEngelen]

Hello I have the same issue here.
I have two HASSIO v 0.92.0 I open both with Chrome on one device it starts with today and on the other device it starts with a date of yesterday.
Both devices have the same hardware.
The device that starts with a date of yesterday has this line in the configuration.yaml:
default_config:
Could this be the issue ?
What can be wrong here ?

[cgtobi]

It appears that the time stamp is lacking time zone information.

[BartEngelen]

Any idea how I can solve it ?

[aplsms]

@cgtobi can you give an example, please...

[cgtobi]

@aplsms for example:

    {
      "datetime": "2019-04-30T00:00:00",
      "temperature": 20.3,
      "templow": 7.8,
      "precipitation": 0.8,
      "wind_speed": 11.17,
      "wind_bearing": 5,
      "condition": "partlycloudy"
    },

Where "datetime": "2019-04-30T00:00:00" should be something like "datetime": "2019-04-30T00:00:00+10:00.

Not 100% sure yet, but this thread describes a similar issue.

[aplsms]

@cgtobi dark sky return timestamp like: "time": 1556520840 and timezone and offset:

    "offset": -7,
    "timezone": "America/Los_Angeles"

so looks like module is not correctly transform the date/time.

on the code we have:

https://github.com/home-assistant/home-assistant/blob/5529bcc1149e60d5bcf93af47fec04e83ac755b3/homeassistant/components/darksky/weather.py#L165

this expression return time and date without tzoffset, like:

datetime.fromtimestamp(1556520840).isoformat()
'2019-04-28T23:54:00'

[aplsms]

i've found some solution:
in python code we need:

1. import pytz
2. replace datetime.fromtimestamp(entry.d.get('time')).isoformat(), to datetime.fromtimestamp(entry.d.get('time')).replace(tzinfo=pytz.timezone(TZONE)).isoformat() where TZONE is field timezone from darksky response.

[bbrendon]

There is a similar issue reported here : https://github.com/bramkragten/custom-ui/issues/28

[rdehuyss]

Also having this issue...

[km4lin]

Same here... Can someone help?

[kpine]

I was having the same problem, weather card showing the previous day. It was working fine until recently. I knew my timezone setting was correct, it was working before wasn't it?

I was testing the Dark Sky API on my local PC, all the times looked fine. The timestamps reported by the API are correct. datetime.fromtimestamp(entry.d.get('time')).isoformat() was reporting the correct local time of the forecast. A few notes about the Dark Sky API and datetime:

1. According to the API docs, the timestamp returned by the API is UNIX time. For daily forecasts the "data point objects to midnight of the day, all according to the local time zone." UNIX times are always based on UTC time.
2. datetime.fromtimestamp will by default convert timestamps to the local platform time if no timezone is specified. So if a) your system timezone is the same as the Dark Sky timezone, no timezone is needed in conversion from the Dark Sky timestamp to string format.
3. The Dark Sky API FAQ recommends always using the timezone property of the response when converting from timestamp to localtime. As @aplsms points out, the Dark Sky component code does not do this. If the system time matches the Dark Sky timezone though, it doesn't matter.

I mentioned I was testing this on my PC, which is important. My HA runs on an RPI3. Just to be sure, I checked the time on my RPI3. Well... it was wrong. It was set to one time zone earlier! This means the conversion from the Dark Sky timestamps to localtime were also one hour earlier. I mentioned above that the daily timestamps are always midnight localtime. Since the set timezone was earlier than the Dark Sky time (based on my coordinates), this was pushing the daily times back one day earlier at 11pm.

The only thing that has changed recently was that I upgraded my RPI from Debian Stretch to Buster. I can only guess that something weird happened during that upgrade to change the timezone, since I never changed it myself. I fixed the timezone and rebooted, and now my Dark Sky forecasts are correct once again.

So I guess my point in this wordy response is double check that the timezone (not just the time) of the HA host is correct, but also that it matches the timezone that Dark Sky thinks you're location is. You can quickly see the results Dark Sky is returning by going to the url https://api.darksky.net/forecast/<secret_key>/<latitude>,<longitude> in your browser (replace secret key, lat/long with yours), there is a timezone field. If your host timezone is "America/Los_Angeles", then the Dark Sky timezone better also be "America/Los_Angeles" or an analogous zone.

The Dark Sky component should probably be updated to always use the response timezone, as recommended, so even if the system time doesn't match the Dark Sky timezone, the forecast will correspond to the time of the location. Or provide an option to use either system time, or location time when converting. But I don't think there's any weather forecaster that would show daily forecasts not in the local time of the location.

BTW, fromtimestamp can convert directly from the Dark Sky timezone string using pytz.

>>> from datetime import datetime
>>> import pytz
>>> now = datetime.now().timestamp()
>>> now
1566369908.604283
>>> datetime.fromtimestamp(now).isoformat()  # localtime
'2019-08-20T23:45:08.604283'
>>> datetime.fromtimestamp(now, pytz.timezone("America/Los_Angeles")).isoformat()  # also localtime
'2019-08-20T23:45:08.604283-07:00'
>>> datetime.fromtimestamp(now, pytz.timezone("America/New_York")).isoformat()  # other timezone
'2019-08-21T02:45:08.604283-04:00'

[stale[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 now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.