input_datetime is an hour out on UK time

[point-4ward]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):*
0.58.1

Python release (python3 --version):
3.6.0

Component/platform:
input_datetime

Description of problem:
In the UK we are currently on GMT. We were on BST until the end of last month (one hour ahead).

Attempting to set the datetime to 19:00 sets it to 20:00.

Component seems to be correcting for an hour forward, as it is taking the time and unnecessarily converting it to BST.

Expected:
Component just accepts that I know what time want to set it to and doesn't convert it to BST, especially as I'm not in BST, and if I was I would still mean 19:00 if that's what I set.

Problem-relevant configuration.yaml entries and steps to reproduce:

input_datetime:
  masterbed_alarm_clock_time:
    name: Time
    has_date: false
    has_time: true
    initial: '06:15'

1. Include above in configuration.yaml whilst in UK timezone
2. Try to set the time to 19:00
3. Scratch head when it changes it to 20:00

Additional info:

(the above sarcasm is sense of humour, not annoyance 😃 )

[point-4ward]

@tinloaf - as discussed on the forums.

[tinloaf]

What exactly is the setting of your

homeassistant:
  time_zone: …

?

[point-4ward]

time_zone: Europe/London

👍

[NigelRook]

Same issue, also time_zone: Europe/London, running version 0.58.0

I'm running inside a docker-container with a /etc/localtime:/etc/localtime:ro volume. gnu date from inside the container outputs, for example Sat Nov 25 19:53:25 GMT 2017 (which was correct).

This appears to be a cosmetic issue only. For example, If I have an input_datetime set to 8:00 am in my config, the card will show 9:00. Clicking on the card will show 9:00 in the top-right corner but 8:00 in the text inputs. The input_datetime's state will be 08:00:00

[SCUZNUTS]

Same issue here with time_zone: Pacific/Auckland

The front end time is one hour behind. The state is the correct time.

[NigelRook]

Had the chance to do some more investigation, looks like it's a chrome bug:-

In chrome dev console:

x = new Date(1970, 0, 1, 6, 0)
Thu Jan 01 1970 06:00:00 GMT+0000 (GMT)
x.toLocaleTimeString("en", {hour: "numeric", minute:"2-digit"})
"7:00 AM"
x = new Date(2000, 0, 1, 6, 0)
Sat Jan 01 2000 06:00:00 GMT+0000 (GMT)
x.toLocaleTimeString("en", {hour: "numeric", minute:"2-digit"})
"6:00 AM"

Also confirmed that the bug does not occur in firefox

Could be fixed by tweaking the default year/month/day in home-assistant-polymer/js/common/util/compute_state_display.js, but maybe that's too big a hammer...

[NigelRook]

HAH! it also works fine before 1968. According to https://en.wikipedia.org/wiki/British_Summer_Time we were GMT+1 all year between 1968 and 1971. I hate coding around daylight saving :(

Created chrome issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=797548

[point-4ward]

(I have no doubt that you know what you are doing, this question is curiosity and not doubting your findings in any way)

Why does Chrome touch the time? Surely the whole point in a Web page is that I say "print 1900 on the screen in green coloured times new roman font" and that's what it does?

[NigelRook]

So, what home-assistant tells chrome to do is "print 19:00 in whatever the local style for displaying times is". 19:00 is an solid example, because that's displayed as 7:00 PM, but PM is an english abbreviation and has different equivalents elsewhere. See https://en.wikipedia.org/wiki/Date_and_time_representation_by_country if you want more info.

[point-4ward]

OK, so, (sorry to sound daft, as you can see I have no idea how this works) but...

Could we not take that option out of the browser's hands and just tell it to print 19:00? (like, send it a string instead)

My thinking being (bare with me):

I set up an input_datetime in my configuration.

I set the time to 1900

My frontend displays 2000 for the reason you've outlined.

BUT, in my devices list the state of the input_datetime is 1900, presumably because it's passed to the browser as a string rather than a 'time'?

Given that the frontend display is purely aesthetic, and given that I don't expect anybody will ever want it to show any time other than the one they've set could we not pass it as a string in the front end too?

[NigelRook]

That's potentially detrimental to some countries, depending on how they conventionally display times. To know whether it's safe, you've gotta start digging from that link I posted.

There's a simpler workaround HA can implement, which is to use the current year/month/day for the date they're required to include to get the browser to render a time, instead of 1970-01-01. Evidently history is scattered with awkward little fiddly daylight saving rules for people to trip over. That particular selection has highlighted two, so it's not unreasonable to assume that any arbitrary selection will do the same. Today is less likely to be buggy :)

I'll see if I can't whip up a quick pr for that now actually, sure that's what you're actually after :)

[point-4ward]

Fair enough, just thinking out loud whilst simultaneously trying to learn something. Everyday is a school day, and as I type this the clock has just changed to midnight going in to Xmas day, so, ummm, Merry Christmas 😀😀

PS - a PR to fix would be an ace stocking filler 😂😂

[NigelRook]

Merry Xmas :)