Frontend: Timestamp shows "Invalid Date" in Safari; but it's properly displayed in Chrome

Created on 23 Oct 2019  路  10Comments  路  Source: home-assistant/frontend

Home Assistant release with the issue:
0.100.2

Last working Home Assistant release (if known):
n/a

Operating environment (Hass.io/Docker/Windows/etc.):
Safari 13.0 on Mac OS 10.14.6, Chrome 77.0.3865.120 on the same Mac OS

Integration:
custom-component/alexa_media_player, but seems to be related to the display, not the sensor

Description of problem:
I use the Alexa Media Player to create some sensors with timestamps (next alarm, reminder, etc). When placed into an entity card, in Safari, I see Invalid Date where in Chrome I see a value like In 10 minutes or In 20 hours. Clicking on the sensor gives values like 2019-10-23 09:51:00+03:00 in both Chrome and Safari

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

alexa_media:
  accounts:
    - email: !secret alexa_email
      password: !secret alexa_password
      url: amazon.com
      debug: True
      exclude_devices:
        - "This Device"

Lovelace card configuration:

entities:
  - entity: sensor.parents_room_next_reminder
  - entity: sensor.parents_room_next_timer
  - entity: sensor.parents_room_next_alarm
title: Alexa Test
type: entities

Traceback (if applicable):
n/a

Additional information:
Original issue was https://github.com/custom-components/alexa_media_player/issues/446, but it seems to be a front-end issue, and only on one browser.

bug

Most helpful comment

I've had this before with template sensors. Internally the timestamp formatting creates a new Javascript Date object from the value of the sensor using new Date(*sensor value*). It appears that Javascript in Safari (and also Chrome on iOS since this actually uses the Safari engine) is more strict with what formats it supports.
Chrome on Mac and Windows is perfectly happy with the format YYYY-MM-DD HH:MM:SSTZD (as with the value "2019-10-23 09:51:00+03:00") but Safari and Chrome on iOS requires it to be in the format YYYY-MM-DDTHH:MM:SSTZD (e.g. "2019-10-23T09:51:00+03:00")

All 10 comments

I can confirm that this also occurs in both Chrome and Safari on iOS, and in the iOS mobile app (beta version)

I've had this before with template sensors. Internally the timestamp formatting creates a new Javascript Date object from the value of the sensor using new Date(*sensor value*). It appears that Javascript in Safari (and also Chrome on iOS since this actually uses the Safari engine) is more strict with what formats it supports.
Chrome on Mac and Windows is perfectly happy with the format YYYY-MM-DD HH:MM:SSTZD (as with the value "2019-10-23 09:51:00+03:00") but Safari and Chrome on iOS requires it to be in the format YYYY-MM-DDTHH:MM:SSTZD (e.g. "2019-10-23T09:51:00+03:00")

Is the conversion from the datetime to the string something that the individual sensor does, or is it an HA-wide function? Is there something that should/can be done in the specific component here? [sorry, I don't really know anything about how this part works]

I posted in the original issue under alexa_media as well, but I'm not sure where this would need to be fixed. The datetime value gets manipulated via javascript in the Entities card, which is what is breaking, but the datetime shows up fine on a Glances card, which isn't manipulated via javascript. So I'm not sure whether the datetime format should be changed at the component level, or manipulated by the javascript in the Entities card. I guess someone involved in the frontend development would need to chime in.

@mikeage As far as I know, sensor states are always strings, so it is the responsibility of the individual components to convert timestamps to the correct format.

It could potentially be fixed centrally by changing hui-sensor-entity-row so it replaces the space in the sensor value with "T" before creating the Date object for hui-timestamp-display.

This was posted by the developer of the alexa_media component in the issue that is opened up under the alexa_media component:
This component is literally using the tools from HA for making the time stamps. It probably should be either in the HA backend or the HA frontend to process it correctly. Since it feels browser specific, that strikes me as a frontend bug. While amp could work around it, the more sustainable fix would be to do it in HA.

The backend should provide the correct date time string for the frontend to work with. So this should be fixed in the backend.

Correct in this case meaning with a T between the day and the hour, as per ISO8601? (which allows skipping it by mutual agreement, but it seems like Safari won鈥檛 agree)

I've added a .isoformat() to each string returned by for the three state functions, and this appears to resolve the issue. Based on my understanding, this is the proper fix (and it's in the backend). I'm closing this based on that understanding (please tell me if I'm wrong and so I can re-open)

Was this page helpful?
0 / 5 - 0 ratings