Changed time last night, hub shows correct time. However, my Night Mode activated at 11:00 PM instead of 10:00 PM. I think I remember this happening before, but I thought it got fixed.
C8-pro running 2.4.0.151.
1 Like
On the positive side, you got a late night... 
Curious is this is a variable used in a dateTime trigger? Not sure if it’s related, but I was having issues with variable dateTime used as triggers firing an hour earlier than they were supposed to. I use them on my dashboard to set the time to open for housekeeper, maintenance, etc. But that was before daylight savings change happened… so maybe they are correct now? I’ll have to test.
Running the same and same thing happened here
I seriously wish we would just get rid of the whole clock changing BS. Team Daylight Savings Time Forever!
3 Likes
I am likely off the mark, but I expect we have reached a point where the challenge is aligning the time between a "server" and client. I would expect the time for both should not matter, but maybe this my mistake....
Same problem here, hub time shows correct but automations are an hour off
Same here - my rules triggered an hour off. I don't remember that happening in the Fall changeover, but it's no fun now.
1 Like
My guess is that the scheduled job was created before the clock changed, and it would have been scheduled using the local offset from UTC time when the job was created. So when it fired, it was one hour off from your new your local time vs UTC.
That is my guess, so now that we are a day out from the clocks changing, I wouldn't expect it to happen again.
5 Likes
From what I recall when there were similar issues last year, staff said that it was too much hassle/wasn't worth the workload to resolve the problem that only occurred one day of the year.
5 Likes
Yeah that’s what I think is going on. IIRC @bravenel once explained that the scheduler is using Unix time so probably as you say with the offset valid at the time the job is set, not at the time the job is run, which is correct 363 days of the year where ever daylight savings is observed (except on leap years 
)
So...this just happened to me tonight - set to turn off lights at 12am, turned them off at 11pm.
So, not isolated to one day? I rebooted my hub, but wondering if there's anything else that needs to be done - remake the lighting app automation?
I had a couple automations that had offsets from sunrise/sunset that I had to resave to get them to update to dst. Automations without offsets worked fine.
I guess the extra hour you get at one point in the year can be accounted for to manage the transition of the smart tech, much like the time spent changing the manual clocks in the house... I guess it all evens itself out in the end...
I have the same problem at every time change, I've posted about it before. I have a date/time variable used as a trigger. I set it Monday night (after the time change). My app did not trigger Tuesday morning. In Settings, hub variables, it shows an hour later than what I set it to, but if I click on the time to change it, the value shown at the bottom is the value I entered, one hour earlier than displayed above. I rebooted the hub, it still shows the same. But if I change the variable again, the values are now the same, and my rule did trigger properly this morning. I'm going to remember to reboot my hub a few hours after each time change, (or write an app to do this), that should fix it for me.
I rebooted my hub and still happening today. Log is clearly showing the lights turn off one hour earlier than it should be.
While I understand something like this may "only occur once a year", lighting automation (at a minimum) is somewhat of a core function and an edge case that should be fixed.
1 Like
It's already accounted for by the hour we just lost. (Hint: There is NO SAVINGS of time. Just adjustments to sleep patterns and ill effects on health to support corporations who want people to shop later in the day)
1 Like
I guess I hadn't thought of it beyond just an inconvenience, it can obviously affect everyone differently.
