No because in the absence of a timezone, it assumes it’s local time. Hass.io always uses local time unless otherwise directed. (Actually the Linux convention is that no time zone specified means the time is local time. That’s why it’s important to have correct time zone set in base OS as well as correct time set in Home Assistant configuration.yaml)
Well - it’s post 10am now and I get True now.
My TZ in configuration.yaml is good now. Does that mean that perhaps my base OS is set incorrectly. How can I check that on Hass.IO running on a Rasberry Pi ?
what’s your OS time? Also what version are you running?
You could always just do this for the time being too
{{ ((as_timestamp(now()) - as_timestamp('2019-05-01 00:00:00'+now().strftime('%z')))) / 86400 |int % 14 < 1 }}
I’m running Hassio 0.92.2 on HassOS 2.12
How can I check the HassOS TZ or time?
Not sure, I don’t run hassOs. There may be a command through SSH
Doesn’t look like there is unfortunately. SSH to host only allows… reboot, shutdown, update
that seems limited, I remember more commands when I was using it. Have you tried hassio help? or hassos help? or help?
homeassistant, ha info, logs, check, restart, start, stop, update
supervisor, su info, logs, reload, update
host, ho reboot, shutdown, update
hardware, hw info, audio
network, ne info, options
snapshots, sn list, info, reload, new, restore, remove
addons, ad list, info, logo, changelog, logs, stats, reload, start, stop, install, uninstall, update
help, h Shows a list of commands or help for one commandShould be able to type in date
I can.
Yep - typing Date returns Thu May 16 15:53:29 AEST 2019 But that must be in HassIO? Not HassOS. (I think)
While you are there and thanks for all this! What do you get if you type the following into template editor?
{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
I get…
2019-05-16 05:55:44.543966+00:00
2019-05-16 15:55:44.544058+10:00
2019-05-16 05:55:44.544186+00:00
2019-05-16 05:55:44.544444+00:00
UTC
Australia/Sydney
UTC
I think {{ now().astimezone() }} should have returned local time and {{ now().astimezone().tzinfo }} should have been AEST.
2019-05-16 06:05:34.531951+00:00
2019-05-16 16:05:34.532000+10:00
2019-05-16 16:05:34.532062+10:00
2019-05-16 16:05:34.532199+10:00
UTC
Australia/Sydney
AEST
Hmm, I’m not in a good place then. I wish I could work out how to set the TZ properly in the OS. Seems I’m stuck.
Thanks David
@DavidFW1960 and @petro
How’s this! When I was writing to you earlier, I was at work - accessing my HA frontend from a unrestricted internet connection. When I needed better access, was also using a VPN to my internal network.
Today, I am physically at home and slugged in my time/date tests and got a good result…
2019-05-18 00:12:10.427579+00:00
2019-05-18 10:12:10.427696+10:00
2019-05-18 10:12:10.427822+10:00
2019-05-18 10:12:10.428069+10:00
UTC
Australia/Sydney
AEST
I have upgraded to 0.93.1, but I thought my problems were with the HassOS TZ.
How strange!!! But good, I suppose…
1 Like
The browser can definitely screw it up…
I had MEGA issues with my ABB usage meter - ABB reports the date/time as 2019-05-18 10:12:10.428069. Home Assistant in Chrome would then format it correctly, but iOS wiule tell me stupid shit like in 10 hours time… When I reformatted the date to full ISO like 2019-05-18T10:12:10.428069+10:00 it was fine on Chrome and iOS.
But I don’t think that’s your issue.
Same laptop and browser - Chrome on Win10
Bizzarro! I’ll just have to keep an eye on behaviour when accessing from different devices and ask other family members what they are seeing.
@petro offered adding +now().strftime('%z') as a nice little backup to TZ mismatch.
If I enter…
{{ as_timestamp('2019-05-01 00:00:00'+now().strftime('%z')) }}
{{ as_timestamp('2019-05-01 00:00:00') }}
They return the same value, so I might stick to the longer string.
Thanks again
(better leave the computer and go and take part in democracy)
PS. I couldn’t help myself… rolled back to v0.92.2, to see what I got. Same good result. So in short I changed nothing and things got better. Although, I suppose v0.93.0 may have issued some new settings to the environment. Dunno!
Yeah it’s something local to you I’m afraid. I have had this package working without missing a beat for a long time.