Based on this quote, is the only thing we have, which I interpreted to be that the device booted at 3am local time, which is the same time reported in the time stamp, but in utc.
1585625355 is Tuesday March 31, 2020 03:29:15am (UTC) and Tuesday March 31, 2020 10:29:15am (Asia/Bangkok). You can see from the post that that time was being displayed (in his local time zone) as ~10:30am. That was not the problem. The problem was that, when adding the timestamp device class, it got displayed as “In 1 hour”, but should have been “6 hours ago” (since he posted at ~4:30pm his time, which was about 6 hours after 10:30am his time.) So, no, it was not 3am-ish local time, it was 3am-ish UTC, and 10am-ish his local time.
And since it’s now 1:30am in Bangkok, I guess we’ll have to wait for more feedback. 
1 Like
In my time zone 
, this third time point which is when it was observed by the user didn’t seem obvious. Good sleuthing. I would agree with you if that assumption is correct.
Really do need to turn on notifications of new replies in the forum, otherwise it’s just pure chance for me to visit the site and see the badge indicating there are! Sorry for the slow response!
I tried the , False addition and that indeed seems to fix the situation. So that is awesome, I’m happy with that. However, if you guys think this is not properly fixing the fault and rather using duct tape to keep down a bandaid, then let’s figure it out.
Configuration :
- platform: mqtt
name: Mac lastboot
state_topic: "systems/mac/status"
icon: mdi:clock
value_template: >-
{{ value_json.lastboot | timestamp_custom('%Y-%m-%dT%H:%M:%S') }}
device_class: timestamp
- platform: mqtt
name: Mac lastboot NEW
state_topic: "systems/mac/status"
icon: mdi:clock
value_template: >-
{{ value_json.lastboot | timestamp_custom('%Y-%m-%dT%H:%M:%S', False) }}
device_class: timestamp
I have just rebooted my Mac, which has the following results
- the reboot happened around 13:27, Bangkok time (+0700)
- timestamp reported by my script is 1586413685
- the “Mac lastboot” sensor reports “In 6 hours”
- the “Mac lastboot NEW” sensor reports “2 minutes ago”
But here comes the funny bits :
- Chrome on my Mac reports “2 minutes ago” and “7 hours ago” (NEW) (so, the reverse!)
- Firefox on my Mac reports as Chrome
- Chrome on my iPhone reports as Safari does on my Mac
I’m proper confused now.
I’m now with @pnbruckner that your devices and maybe specific browsers have weird time zone issues. This is an area where I have no idea.
Yep, according to a Unix timestamp conversion site:
1586413685 converts to Thursday April 09, 2020 13:28:05 (pm) in time zone Asia/Bangkok (+07)
The offset (difference to Greenwich Time/GMT) is +07:00 or in seconds 25200.
So that timestamp seems correct.
I’m still of the opinion that the first of the two sensors is correct (i.e., with the local parameter of timestamp_custom not specified or set to True, which is the default.)
It certainly does appear that some of your OS/browser combinations are wrong. Not sure what else to tell you, nor do I have any idea how to fix it.
It’s either that, or the problem is with Safari.
I’ve created a page on my HA install and collected screenshots from devices in Bangkok (both on my devices as well as my friends), the Netherlands and London (UK). And I’ve concluded that the problem is not with my local settings.
Here is how I think this all works :
- I provide a UNIX epoch as a datapoint, this by default is a time in seconds since 00:00:00 on Jan 1, 1970 UTC. The last bit is important. A UNIX timestamp is always in the UTC timezone.
- Using a
value_templateand thetimestamp_customfeature, I pour this UNIX epoch into a specifically formatted string. I telltimestamp_customif this should be a timestamp in my local timezone, or if this should be something in UTC. But the resulting string has no indication of timezone included. It’s important to note that this ‘local’ timezone is local for the machine on which Home Assistant is running. - The frontend that is executed on the viewers computer takes this string as input, and assumes it is a local time from the perspective of the local viewer. It then compares this to the local time on the computer, and creates a relative statement of the input being “x minutes ago” or whatever.
The way this is now set up causes a problem when logging in from a timezone other than the one where Home Assistant is running: timestamps for things that have already happened, look like they are going to happen in the future. For example, in my case, I show when systems have last booted and when rendering them in a client accessing HA from Europe, it says my last boot was “In 5 hours”.
An additional problem I’ve found is that Safari renders the relative chunks incorrectly, no matter where you are.
Note: The above has used 6 different devices as source data, so I doubt timezone settings in a browser (which I can’t find to begin with!) are causing these issues.
OH! You’re running the browser on a machine in a different time zone. Well, that explains it!
Here’s one more try:
- platform: mqtt
name: Mac lastboot
state_topic: "systems/mac/status"
icon: mdi:clock
value_template: >
{% set s = value_json.lastboot | timestamp_custom('%Y-%m-%dT%H:%M:%S%z') %}
{{ s[:-2] ~ ':' ~ s[-2:] }}
device_class: timestamp
When I originally suggested adding %z that resulted in the time zone suffix looking like +0700. That worked on my browser (Chrome on Windows), but didn’t work for you. Maybe adding the colon will help, which is what the above should do. Now the time zone suffix will look like +07:00. Might be worth a try.
Actually, I’m not running HA and my workstation in different timezones. It’s just a conclusion from collecting screenshots from a few friends who are in different timezones.
However, weirdly and shockingly, this approach seems to have done the trick. Not only does it behave consistently across different browsers, it also behaves consistently across timezones!
Not including the timezone still causes issues, which I still think is a problem. But I’m closing this case, and moving on.
Thanks to you both for your persistent help in trying to get this resolved. Sincerely appreciated!
1 Like