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.
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.
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.
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, ...it 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" ?
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.
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"?
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?
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.
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.
