"Internal" time wrong

Are you using Lovelace?

Check out this topic:

I am using lovelace as well as states. But just Lovelace in this instance.

But better yet - you got me there…

So…
Chrome on Mac - Works
Safari on Mac - No
Home Assistant Companion on iPhone - No
Home Assistant Companion on iPhone w/ “Open links in Chrome” - No
Home Assistant Companion on iPad - No
Home Assistant Companion on iPad w/ “Open links in Chrome” - No

Seems to be a conspiracy.

Man, my GoogleFu must be getting weak. Sweet find - That topic is me.

Thanks for your help.

1 Like

I’m running Hass.io version 88.1 and see that my “last Triggered” times are 5 hours off. Time zone is set to America/New_York" and the pi CLI reports the correct time. In the folder /etc there is a file called TZ which has UTC in it. So I changed it to America/New_York.

This didn’t correct the log time.

From the pi CLI, what does this show:

timedatectl status

From the HA Template Editor, what does this show:

{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}

timedatectl status == -bash timedatectl: command not found

HA Template editor:

2019-03-07 17:34:23.873535+00:00
2019-03-07 12:34:23.873642-05:00
2019-03-07 12:34:23.873779-05:00
2019-03-07 12:34:23.875721-05:00
UTC
America/New_York
EST

Obviously it’s still on UTC time. I didn’t want to put UTC+5 since it will change for DST.

Not surprised. Hassio!

That looks correct. That indicates the clock seems to be set correctly, and that both HA and the environment in which it runs is set to the same time zone.

So what isn’t working correctly again?

FYI, the last_triggered attribute of automations are represented in UTC. That’s expected, and there’s nothing wrong with that. If you want to represent them in your local time zone, say via a template sensor, that’s easily done.

1 Like

Thanks @pnbruckner. You called it with the FYI.
Everything did seem to have the correct time except when I was troubleshooting an automation problem and looking at the dev-states page. I saw that the last triggered time was in the future by 5 hours :astonished:
Cheers.

1 Like

@lev2000 would you mind letting me know where you found “home-assistant.service”. I think I have a bad setting in HassOS.

@pnbruckner I’m in Sydney, Australia and seem to be having issues. I’m running HassIO.

If I enter…

{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}

I get…

2019-05-16 02:41:06.563020+00:00
2019-05-16 12:41:06.563113+10:00
2019-05-16 02:41:06.563234+00:00
2019-05-16 02:41:06.563491+00:00
UTC
Australia/Sydney
UTC

Does that look correct? I think the last line should be AEST for my TZ

The time zone setting in the environment HA is running in is set to UTC but it should be your local time zone.

Thanks for getting back, so does that mean {{ now().astimezone().tzinfo }} should have returned UTC or AEST?

Is there a way to set the environment / HassOS timezone when running HassIO on a Pi? There is a command interface via Configurator. SSH does not seem to have any time options when issuing commands to host. Thanks

I’m having the same issue. Did you manage to solve it?

The Hassio UI is showing the correct Sydney time
But the Log file is showing UTC time

How can I change the OS time?

@Milster @RKor

I have no idea how to set the environment’s time zone when using hassio & hassos. I use a venv install. But if you search this forum you should be able to find it. I know it’s been discussed a zillion times.

OK, thanks. Love Life360 btw!!!

1 Like

I’m having a similar problem, though I first noticed it with alerts - alerts I set for 2 minutes fire 7 hours (my time zone difference) and 2 minutes later.

Running the time zone commands in template editor seems to indicate astimezone is UTC, but tzinfo is America/Los_Angeles

{{ now() }}
{{ now().astimezone() }}
{{ utcnow().astimezone() }}
{{ now().now() }}
{{ now().today() }}
{{ now().utcnow() }}
{{ utcnow() }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
{{ utcnow().tzinfo }}
2019-05-31 11:26:19.773069-07:00
2019-05-31 18:26:19.773223+00:00
2019-05-31 18:26:19.775135+00:00
2019-05-31 18:26:19.775495
2019-05-31 18:26:19.775705
2019-05-31 18:26:19.775898
2019-05-31 18:26:19.775936+00:00
America/Los_Angeles
UTC
UTC

It seems that somehow my Python environment has the wrong time zone. However, I have no idea how to fix this.

My previous thread, in case there’s useful info there:

I was able to change the timezone in my config.yaml and now my timed alerts are firing every 2 minutes as expected instead of every 7 hours and 2 minutes.

I’d much rather be able to actually use the time zone I’m in, but at least I have a work around for now.

I have a similar error like above, but I’m not sure exactly where the problem is.

Running Hassio
Got my recorder running on mariadb as an addon from hassio
Timezone is set to Europe/Stockholm in configuration.yaml.

Everything in the GUI is correct, looking at the history of a device shows the correct time, but if I do a value_template on the “last_changed” attribute, that time is 2 hours wrong. (seems to be using UTC time).

I just did a reebot of my server at 21:10 (24h time) and below template gives me “19:10”

value_template: "{{ states.binary_sensor.ytterdorr_las.last_changed.strftime('%H:%M') }}"

But looking at the gui, the time of last_changed is correct at “21:10”.

Is this to be expected? If so, how could I write my value templates to show me the correct time?


{{ now() }}
{{ now().astimezone() }}
{{ utcnow().astimezone() }}
{{ now().now() }}
{{ now().today() }}
{{ now().utcnow() }}
{{ utcnow() }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
{{ utcnow().tzinfo }}
2019-09-05 21:18:55.749530+02:00
2019-09-05 21:18:55.749606+02:00
2019-09-05 21:18:55.749749+02:00
2019-09-05 21:18:55.749854
2019-09-05 21:18:55.749914
2019-09-05 19:18:55.749967
2019-09-05 19:18:55.749976+00:00
Europe/Stockholm
CEST
UTC