Automation rules not firing during daylight savings leap foward

Oh :frowning:

Sounds like you found a reason to change it :joy:

My backups are scheduled for 2;16 am, on the 13TH, occurred at 4:35 am

1 Like

my backups, scheduled for 2:16am (hubitat default) did NOT run at any time on the 13th

2 Likes

Ok so sounds like this is not working as expected and there's a bug here. Do I need to file a bug report somewhere or does this thread count?

Probably no need to raise an issue separately, since @bravenel is already participating in the discussion here.

We know that there are schedule failures that occur during DST switchover. Best to avoid having anything scheduled between 1AM and 3AM.

1 Like

Coincidentally those of us in the US might not have to worry about this for much longer

Why don't they just make standard time permanent. It's weird not having noon at the highest point of the Sun.

2 Likes

s/weird/simply stupid/

In most places on Earth, solar noon (meridian crossing) does not happen at 12 o'clock.

Because of standardized timezones. But it does happen closer to 12 than 1 PM. PM means something.

Stay on standard time, "why does it get dark so early?" in the summer. Stay on savings time, "why does it get light so late?" in the winter. No free lunches.

3 Likes

Correct, and even if the Senate bill ultimately becomes law, it would only apply to the United States. So bugs in the Quartz scheduler still need to be fixed, because Hubitat is used throughout the world.

2 Likes

So, I use mode manager to change my modes, and it goes from evening mode to night mode at 11:45pm. Last night (Sunday, March 12, 11:45pm, mode manager did not automatically change to evening to night. This is happened last fall as well.

At first, I thought, "well, maybe it just missed the 'spring forward', so I waited until 12:45am Monday, and still no mode changed. I had to set it manually.

And I'll wager that everything will work fine going forward... Any idea why mode manager misses this change? If I was changing it between 2am and 3am, sure, I could see it messing up... but this was, what, 11 hours after the time change...

I don't have rules set up by time... just by modes, so I don't know if this would also be in RM, or etc...

1 Like

Did you try opening Mode Manager and hitting Done? That would refresh its schedules. We conquered most of the DST change issues, and I'm not at all sure why Mode Manager would fail at this. Also, in the past when we had DST change problems, they clear up after the first day.

And here I was actually thinking there would be no DST problems this year! :slight_smile:

1 Like

Changing the mode manually kicked everything off properly.. (rules are based on a mode change state), and it's been running fine ever since... Unfortunately, I won't be able to test anything again until next fall.. :wink:

What I'm a little confused about is that none of my mode changes are any where near the actual time change... Even if they were batch files, you'd think the system updating it's time would not impact scheduled events at other times... I'm not sure how Mode Manager runs it's schedule, but, the mode table is below (if it helps).

Lastly, this was a fresh backup/restore from a C-7 to C-8 hub, again, if that helps at all..

image

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.