I am in the UK, which is time zone GMT+1 currently; I noticed my automations were running 1hr late, then I realised my time zone was set to UTC.
So I went to switch it to “Europe/London” GMT+0; it is aligned to UK time now, despite showing GMT+0 which slightly confuses me.
We are one month into the british summer time
Can anyone shed some light on this please? I am also confused as to why currently in summer, the Time Zone shows (GMT+0) rather than (GMT+1)
+1
This is still broken/wrong. It’s causing me some issues with scripts and automations.
Specifically, if I set a notification with a chronometer “when” of {{ (now().strftime(\"%s\") | int + (5 * 60)) }}, I get now() + 3900, not now() + 300.
I understand that I could just compensate for the drift, but that would be a manual task across multiple automations, or changing the timezone of the entire server twice a year, which seems like it would cause numerous log instability issues.
What install method are you using and what is your TZ set to? Are you running in a VM?
As a sidebar, this is only happening to you. There’s a confirmed ~50k users in this time zone that do not have this problem. It is unique to your system.
I’m using a preinstalled Home Assistant Blue, and my timezone is set as London (GMT+0) (which is odd, as london is currently GMT+1. No VM.
I think I’ve narrowed the problem down to the now().strftime(\"%s\") (specifically the %s), as I can get the correct result if I run as_timestamp(now()), but the previous line of code gives me the wrong adds an our on.
For more context, my history logs seem fine (eg: motion sensors showing the correct time for motion outside, etc).
I think the (GMT+00:00) London might be a human/visual error (see my attached screenshot), as I can see that the actual timezone being passed to the backend is Europe/London, which is correct, and any time system worth it’s salt will be fine with that. (Hell, if that’s the problem, it’s not Hassio, it’s Python that’s at fault).
PS: Sorry, some of this was brain dump, and I re-wrote massive chunks on the fly as I discovered things, and I was trying to find data points to help track the problem down. If clarification is needed on anything just ask. I’ll do my best to make more sense.
PPS: as_timestamp(now()) solves my original issue, as {{ as_timestamp(now()) | int + (5 * 60) }} gives me exactly what I was looking to do. I’m still happy to help track down why this is happening, in case it happens to anyone else that’s casually looking for a solution.
This is 2 years old now, I have it set to this
and automations are run at the time I set them
I don’t remember exactly what issue I was having, but if you select the city corrisponding to your time zone, it seems to be working, despite the GMT+x being wrong
What does now() produce in the template editor?
The UK timezone is GMT+00:00 all year. Time is measured referenced to UTC which is equivalent but not equal to GMT or timezone Z(Zulu). Geographical and political timezones are referenced back to GMT as +/- hh:mm, so Central European Time (CET) is GMT+01:00 or timezone ‘A’.
HA like all computers uses UTC internally. At display, or in automations, using Javascript for example, there are functions to turn the base UTC to local time. This uses local machine timezone settings to add or subtract the correct number of hours from the UTC value.
Daylight Saving (DST) applies in various political locations, and shifts the local time by one hour. In the UK we have BST. We do not move timezone, we just apply DST to our local time presentation. Javascript, used in web browsers, is DST aware and correctly adjusts the base UTC time at the point of display to account for both the timezone shift from GMT and current DST.
All time inside HA is UTC. The fun starts when we either display or use that time. For example, I am currently writing this on holiday in Spain. Using NabuCasa I can view my HA back home, and some of my times are showing as GMT+2. This is because my smartphone has switched my local timezone to Madrid as CET or GMT+1, and is also adding DST. Hence 21:00 UTC is 22:00 in the UK but 23:00 on my phone in Spain. This is confusing but correct.
now() in any computer will generate UTC. To be absolutely correct, it is imperative to either turn this into ‘local’ time to use for display and timers, or to retain as UTC for comparison with any other stored UTC timestamp.
Your base issue was due to comparing UTC ‘now’ with local time (BST), which uniquely for those of us in the UK works in the winter but not the summer.
Time zone issue here as well. I want to receive a message at 23.35 hours. That worked at home - Brussels GMT+01:00.
I’m now in Egypt - GMT+02:00 - and still receive the message at Brussels time, meaning 00.35 hours in Egypte. Which is one hour later than needed.
Settings are correct, set at local time (Africa-Cairo) instead of server time.
alias: Overzicht van je activiteit naar iPhone Herman
description: ""
trigger:
- platform: time
at: "23:35:00"
condition: []
action:
- service: notify.mobile_app_iphone_herman
data:
message: >-
Je hebt vandaag {{states("sensor.iphone_herman_distance")}} meter
gestapt, {{states("sensor.iphone_herman_floors_ascended")}} trappen op
gelopen en {{states("sensor.iphone_herman_floors_descended")}} trappen
af gelopen.
title: Fijne nacht, Herman!
mode: single
Yes, time is a very simple concept, until you are in two different places (at the same time, which it is not). And I should really correct some of my reply above as it is not entirely accurate.
If you have a server (the HA device) in Brussels, and you have a smart phone in Egypt, you can have a time difference that can be very difficult to deal with.
The HA device works entirely in UTC (Universal Coordinated Time) no matter what the location is.
The ‘location’ setting and time zone offset setting is used to determine the machine ‘local time’.
23:35 CET (Central European Time) during DST (Daylight Saving Time) is UTC +2, and is therefore 21:35 UTC. Note that local time is UTC +1 hour for CET and another +1 hour for European DST.
Almost all display / automations in HA work in local time, so the location setting is used to adjust the time at the point of use. Set for Brussels at GMT+1 clearly works, and this also successfully takes into account the DST shift during the correct time period (last Sunday in March to last Sunday in October, change at 01:00 UTC).
I am in the UK, which is on BST (GMT as DST), so my HA UTC times are moved +1 hour forwards to BST on display. The complexity of this is shown when I used nabucasa link to view my HA when I was travelling in Europe. My smart phone, using the mobile signal, worked out that it was on CEST (Central Europe Summer Time) and moved my time forward by a further one hour. When I looked at some of my dashboard display, the base UTC time that was being displayed was moved to local time - which was the time local to my phone (and hence the JavaScript on my phone, using the machine location settings).
You can see that the UTC time is shown as CEST time, whereas it would normally appear either as GMT (winter) or BST (summer), and yes the time was correct but just one hour more than it would be back in the UK.
Now, if you are in Egypt the time is one hour further ahead, being based on GMT+2. Egypt also has DST, which is much more complicated than European (and UK) DST.
https://en.wikipedia.org/wiki/Egypt_Standard_Time
I note from the above that DST has come back into use just this year, and runs from the last Friday in April to the last Thursday in October, with the change at 00:00 local time.
To correct my posting above, I quote, from https://stackoverflow.com/tags/timezone/info
The point with offsets is that the machine works out local time as +/- hours based on UTC, hence UK would be +0, Brussels +1, and Egypt +2. The computer can easily work out the time shift from this setting, but has no idea about DST.
The point with time zones and DST is that this is a temporary +1 hour shift, applied using local political rules and dates and times. A computer by itself has no chance whatsoever of knowing if DST is ‘ON’ or ‘OFF’, and this has to be done by looking it up. The question is, what does HA (as a server) do to find the time zone DST setting? I assume that HA is using the device location (NOT the time zone offset) to look up the full time zone info including the DST. Indeed, HA may be using a mix of both - using the time zone offset for the hour shift each time this is required, but also using the location to do a (only on start-up) time zone lookup for the full DST info, based on the device location settings.
https://www.timeanddate.com/news/time/dst-egypt-2023.html
So, if your HA device is in Egypt (or at least thinks it is) and you have set the machine time offset (time zone) to GMT+02:00, it should know that 23:35 local time is 20:35 UTC, and then trigger at that point.
In looking on the web I see that my current time in the UK is 16:30, in Brussels it is 17:30, and in Cairo it is 18:30. However, I am finding other ‘time’ sites that show local time in Cairo is 17:30 - because they have not updated for DST.
I wonder if you have updated the time zone (correctly called the offset) to +02:00, but have left the HA machine location as Brussels?
In this case the machine thinks it is in Brussels and on GMT+02:00 CEST, whereas you want it to be in Cairo and on GMT+03:00 EEST.
Of course, on Friday and Saturday this week your notification should work, since the Egypt DST stops and the EU DST does not, so Cairo will be on the same time as Brussels (for two days).
Time for a coffee…
The backend has no concept of the frontend user’s timezone. So the backend will just output the timezone where the server is located. Notifications are sent from the backend.
I am in the UK.
My machine is set to a UK location (physical coordinates).
My machine is set to time zone (should be called ‘offset’) as GMT+00:00
The current time is currently DST so is BST or +1 hour.
I set a trigger platform time for “08:30:00”.
The back end is at 07:30 UTC. Me and my house are at 08:30 BST.
At what time (local) does the HA backend trigger the event? Is this triggered by the backend looking at the local time and trigger setting, or by the backend moving the trigger setting to UTC and comparing that?
And, as we are on the subject and I really want to know -
When we put the clocks back next Sunday at 01:00 UTC, how quickly does HA update the local time? I ask because I am looking at using Octopus Flux - which has energy off peak charges between 02:00 to 05:00 local time (not UTC) and I will need HA to get the time change effected ASAP!
Just interested…
It triggers at 8:30 your backend timezone.
The backend is not utc. The backend uses utc to store values, but it works off your tz.
DST is set when DST is applied/not applied. i.e. the moment it changes from +1 to +0 or +0 to +1. That depends on your timezone. For most, its 2:00, 1:00, or 3:00.
Well you certainly learn something new everyday. I thought all Unix based machines ran to Unix Epoch millisecond time based on UTC internally…
I am going to set an alarm for 01:45 next Sunday as I want to watch my Home Assistant backend change the time at 02:00 BST to 01:00 GMT and see exactly when it happens. Be interesting to experience 01:45 twice in one night too…
I think you’re miss understanding the difference between executing at a time vs providing a serialized timestamp. Almost all coding languages handle time based on your locally set TZ. Deep deep deep under the hood they use unix time, but when you request the time, it most certainly will be local unless you specify UTC. When you look at automations or scripts or traces, they have serialized timestamps that are UTC, that does not mean the system does things based on UTC. That just means HA stores the values in UTC so that it can be easily translated in the frontend to whatever timezone your user sets.
Your TZ doesn’t change. Only your DST. That’s how python works. It just adds or removes the offset for your TZ.
