Automation rules not firing during daylight savings leap foward

Hey all,

Yesterday my timezone switched from standard to daylight savings time at 2AM and leapt forward by an hour. In the morning I noticed that my Simple Automation Rules tasks that were scheduled to fire at 2:30AM did not run. I realize it's caused by the fact that it was never "technically" 2:30AM that day but I assumed the hub would run all missed tasks during this scenario. Is this an issue with Simple Automation Rules specifically or does it apply to all scheduled tasks on the hub? If it's specific to SAR I can switch to Rule Machine or another app.

Any help would be appreciated!

First, of course anything set for that hour would not run, since that time did not happen. Second, the hub would never run an automation at some later time on its own. Depending on the specifics this could be a very bad idea (might be good for you while disaster for someone else). So, ultimately it is up to you to be aware of the missing hour once a year, and accommodate your needs as you see best. This applies to the hub, not just Simple Automation Rules.


Gotcha. I guess the simplest solution is to just change the task to have it run at 3AM ¯_(ツ)_/¯


Another weirdness is the hour between 1:00 AM and 2:00 AM in the fall, when 'fall back' would cause a scheduled event to happen twice. For year round reliability in the wee hours, either move to a place with no DST (ha! like where I live in AZ), or avoid 1 AM to 3 AM.


if the 2:30a is important, you could implement the variables necessary to pick off the correct day and adjust the rule to suit.

The driver I built can accommodate understanding the DST flag change using the provided variables.

DST changes also affect the automatic backups. My hub is set to backup at 2:16 am. Odd time, I didn't pick that, it's just been that way and there has been no reason to change it. Today I checked the backups and there was no backup for 2-13, since 2:16 am didn't happen.

It most certainly did. The only thing the DST change does is change which enumeration of time we use. 2 AM EST is 3 AM EDT. There was a 2:30 AM EST, and there was a 2:30 AM EDT, both of which happened. Skipping rules because of a change in "wall time" isn't correct behavior.

Vixie cron (and most crons) has handled this reasonably "forever":

Daylight Saving Time and other time changes

Local time changes of less than three hours, such as those caused
by the start or end of Daylight Saving Time, are handled specially.
This only applies to jobs that run at a specific time and jobs that
are run with a granularity greater than one hour. Jobs that run
more frequently are scheduled normally.

If time has moved forward, those jobs that would have run in the
interval that has been skipped will be run immediately.
Conversely, if time has moved backward, care is taken to avoid running
jobs twice.

Time changes of more than 3 hours are considered to be corrections to
the clock or timezone, and the new time is used immediately.


Had no clue that the utilitarian rules run in exactly this time window (because it's quiet) would be totally skipped. Ironically, I was just asked tonight.... Q: "did the Hubitat light schedule change with DST". My A: "oh, yeah...of course, it picks up the time change and knows how to handle everything"

It's not a big deal, until as mentioned, is for somebody expecting the opposite behavior. My default thought would have been that the time change causes things to be fired early/late. I would have gone, "oh, yeah, right" vs "what the hell, it didn't even happen" ?

And now I know. Will the next guy/gal ?

When you have been automating things for a very long time, you learn to avoid daily things that happen between 1:00-3:00 AM, for all the reasons noted and argued. Life's simpler that way.

1 Like

As I'm in the UK, I could approach this topic differently - DST starts 27 March here . To that end, what's the difference between "GMT", "GMT0" and "Greenwich" in the Localisation settings? And what is "GB"?

You could set the thing to run 12 hours earlier, and start the rule with a 12 hour delay :smiley:


They're all equivalent, assuming HE follows the standard use of TZ names. They don't do BST, and are equivalent to UTC for practical purposes.

GB (same as Europe/London) does reflect the summertime change, and is what you should use if you want events to use "wall time."

Are you sure? When I look at a device, Scheduled Jobs are shown at a specific time in the future. When creating a delayed rule, is it actually scheduled as an interval, or does HE simply add the delay to the current time and schedule for a future specific time? And if so, does that calculation reflect any upcoming DST change?

Thanks Mike

I've never heard GMT0 used, despite working in IT since the mid 1980s. Greenwich is just odd - if it's short for GMT then why not just use that? Greenwich itself is a place in London, and most certainly does use BST

You are right, and I was wrong above. Quartz does store schedules with epoch time, so it should be immune to DST. That thing scheduled for 2:30 should have run at 3:30 on that one day (2-1/2 hours after midnight). Perhaps the OP didn't look at the right portion of the logs?

Also, come to think of it, the bit about something between 1AM and 2AM running twice is wrong also, for the same reason -- there is only a single cron entry for a specific time, so it should run on the first 1:30AM, and not the second.

I just double checked and confirmed the task did not run that day. Is that expected or a bug? A bit confused now

1 Like

From what @bravenel posted just above you, it would not be expected.

Can you post the screenshot of this rule?

Yeah here's the rule. I've since changed the time to 3AM but it used to be 2:30AM.

Here's a screenshot of the event log for the rule. There's no entry for 3-13. It jumps from 3-12 directly to 3-14.

Same for automated backups scheduled for 2:16 am (default) on Settings > Backup and Restore. I have, however, been considering the workaround of moving to Arizona. Sedona was really nice when my wife and I visited there this past summer.


Download the Hubitat app