I’m running HassIo on a VM and my local time is 6 hours behind what it says in the system log and automation triggers. The time is correct in the Logbook. I used Putty and ran the Date command and the timezone and time are correct. Something appears to be set as UTC as that time is exactly 6 hours ahead of my time zone. Anyone know how to explain how to change this to a Linux illiterate?
The HA back end uses UTC time. it only converts to local time when displaying times in the front end.
I kinda came to that conclusion too. Certainly there is a way to correct it?
1 Like
No. This is the way HA (and all servers I know of) operate.
Keeping one standard time internally simplifies things greatly.
Your description is a little confusing. Here is what you should see for the various time displays:
- Timestamps at the beginning of each line in home-assistant.log should be local time (with no time zone offset shown.)
- Timestamps in the Logbook and time scales on the History page should be local time (again, with no time zone offset values shown.)
- Time triggers in automations are local times and should cause the automation to trigger at that local time.
- Times shown for entities in the frontend are generally in local time (unless they specifically show a time zone offset, such as “-06:00” or “+00:00”.)
- Entity attributes that are date/times are generally in UTC, but not always. They should have a time zone offset (such as “+00:00”, which is UTC, or “-06:00”, which I believe is your local time zone.) If they don’t, then they should be in local time.
There may be some exceptions to these rules, but that’s what you should see for the most part. If not, then something is probably not set correctly.
Does that help?
EDIT: I should probably also say, if a time is shown with a time zone offset, then the time shown with it should be appropriate to that time zone. E.g., if it shows “+00:00” for UTC, then it should, in your case, be six hours ahead of your local time. If it shows “-06:00”, then it should be your local time.
If I view one of the automations in the States page it says:
last_triggered: 2019-01-19T03:31:09.926208+00:00
I’m guessing the end says there is no offset?
In the System Log (Hass.io/system tab) It is obviously UTC because it shows things that have happened in the “future”.
The Logbook and History are local time.
Seems like it should be pretty easy to just change it to be the same as the host computer. I’m guessing it is not or impossible.
When I say “no offset shown”, I mean without the “+NN:NN” or “-NN:NN” (aka utcoffset) suffix. Without the suffix it’s what is called “naive”, meaning it does not indicate a time zone. By itself you have no idea what time zone it represents … unless you know something about where it comes from. (E.g., I happen to know that the timestamps displayed in the Logbook, and the time scales on the History page, although “naive”, are in the local time zone, or, at least, are supposed to be if everything is configured correctly.) But if you see a time with a utcoffset, then it’s a “time zone aware” time, and it’s unambiguous.
So, when you see “last_triggered: 2019-01-19T03:31:09.926208+00:00”, that’s a time zone aware time in UTC (because the offset is zero.) When that automation triggered, what time did it happen in your local time zone? Was it 3:31 am on the 19th? If so, then your HA time zone configuration is probably wrong, because that UTC time means 9:31 pm on the 18th in your local time zone (since you’ve said UTC is six hours ahead of your local time zone.)
I don’t use Hass.io, so I don’t know how the “System Log” works. I do know how the timestamps work in home-assistant.log, though. (Maybe they’re the same???) In home-assistant.log, as I’ve said, the timestamps at the beginning of each line are naive times in the local time zone. If they are “in the local future”, then something is definitely configured incorrectly.
Bottom line: The time zone setting in the environment in which HA runs (typically the underlying OS, but not always), must agree with the time_zone in HA’s configuration.yaml. And, of course, the clock in the environment needs to be set correctly.
So it appears the only place they are incorrect is in the System Log (which appears to be more of a log for items on the /hassio/dashboard, ie: addons & snapshots) and the filter attributes on the States page. They are correct in the home-assistant.log. For troubleshooting purposes it would be nice to look at the automation attribute and see a local timestamp trigger instead of UTC.
I figured I could easily change the timezone on my VM much like I can on Windows but TBH I don’t know how to do that. If I SSH into HA with Putty and run the date command it comes back as local time. I’m guessing doing that is not the same as getting into the “main” VM. If my understanding of HA and Ubuntu is correct that would be like trying to change the timezone in Word (a program) instead of Windows (an OS).
What do you mean by a VM? Are you using something like VBox or VMware, or are you using Docker containers? If the former, then you should be able to set the time zone and clock inside the OS running in the VM just like you do without a VM (I think.) But I don’t use Dockers so I don’t know how that is done. If you are using Docker, then maybe someone with Docker experience can tell you how to make sure the time and time zone are correct inside the Docker container that HA is running in.
But even when you get everything configured correctly, you’re still going to have to deal with the fact that many times are in UTC. If you look in the attributes column, nearly all of them are.
The VM I’m using is VirtualBox. If I’m understanding you correctly the timestamp in the attributes column will always be in UTC regardless of what I change?
So you should be able to open a shell inside the VM then (somehow, maybe ssh into it) and check the clock and time zone settings.
Not all attributes are in UTC, but most are. If you see “+00:00”, then as I said, it’s a time zone aware datetime in UTC. Note also many of these are actually Python datetime objects, but some may be string representations of them. If you want to display any of these in the frontend you can always uses templates to convert to local time.
I am a bit confused…
I have been running HA in a docker for more than a year with version 0.63 until November 2019 (it is easier to manage broalink devices)
I have then switched to a Raspberry Pi 4 and hassio HassOS 3.9 Home Assistant 0.105.2
And now, logbook and automation are showing the wrong time stamps.
I am at GMT +07:00 Asia/Bangkok
Hardware is showing correct date local time (+7) and date -u is showing correct UTC
HA system log is showing normal local time
Logbook and automation is showing time stamp one hour after UTC, so local time minus 6 hours.
It does not affect the automation, but it is a bit disturbing when reading the logbook or devices events.
Solved…
Computer just needed a reboot after traveling to France 
I am happy with the logic that the host records everything using UTC.
However, when I view data in the front-end whilst sitting in a location 11 hrs ahead it does my head in trying to work out when things triggered. Simple things like the logbook shows no data when I use it in the mornings because it is still the previous day in the HA system’s clock. The events in Logbook are grouped by day if I select ‘week’ for example but half of my HA system’s data for each day is grouped into in one day and half in the next.
Another example, Pete was actually at work from 08:42 to 16:52, but HA shows this.
Has anyone worked out how to persuade a browser pretend to be in the host’s timezone so as to display the data sensibly in host’s localtime. I use chrome on Windows 10.
I think I’ve cracked it. There is an add-on for google chrome called ‘change-timezone’ which allows me to toggle between two timezones and suddenly it looks sensible.!
Spoke too soon. That add-in is very flakey. Back to the original situation.
I will barge in here too, sorry.
So what do we do if the DHCP request will be broken because of time difference between the Home assistant server and the DHCP server? This is what I am experiencing. After the 2 hour lease, HA loses its IP and can’t get it renewed.
For me, hassio.supervisor log was in UTC but everything else was ok. My solution as per alpine-docker threads I read on the subject was…connect to the docker container as root. Then, find your timezone in /usr/sbin/zoneinfo and ‘cat’ that file to /etc/localtime.
i.e. cat /usr/share/zoneinfo/Canada/Pacific > /etc/localtime
Then systemctl restart hassio.supervisor. This fixed my Supervisor log file recording in UTC.
1 Like
This fixed it for me, however there’s a typo in your cat command, the location of zoneinfo is at /usr/share/zoneinfo.
Also, will this survive a supervisor update?
Thanks, I’ve corrected my error. I don’t know how I came up with “sbin”!
I’ve updated my HA Core since posting from 114 beta to 114.0 then 114.1 and I just checked my supervisor… as of yesterday it became v 235 and the change did not survive.