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.
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.
That’s great, so as long as you don’t completely remove the Supervisor container, it should persist forever then. Be nice if this could get properly fixed though. Considering that all the other logs that show a date/time stamp show in local time, can’t imagine the supervisor logs is supposed to be the oddball one. Also, /etc/localtime did not exist for me at all, and if it was intended to be in UTC, shouldn’t that file be set for UTC?
No, without /etc/localtime, Linux defaults to UTC.
This issue start for me since ver 117.
I copied the zoneinfo file to /etc/localtime, but after restarting it disapeared and the log stay on UTC.
I’m now on the new HA Blue ODROID device. Initialized the installed HA image, restored my backup and everything is fine including time so I’m not sure how I can help you figure it out…
I made a userscript to display Supervisor logs in local time rather than the weird UTC format (2 digit year) that it currently displays in the browser. I have tested it in Firefox with the Tampermonkey extension. You can use similar extensions on your preferred browser.
The userscript assumes that your Supervisor log’s URL is http://homeassistant.local:8123/hassio/system (line 7). You can change this value or add another // @match entry with the correct URL for your environment. Feel free to make any other modifications to the script to display the time in your preferred format. The Intl.DateTimeFormat documentation shows the possible values you can use.
I wanted to create a patch for the Home Assistant Frontend to do this automatically, but setting up the developer environment to show the Supervisor became a stumbling block.