FYI, I have this rule that triggers on a periodic schedule of every 10 minutes. In the actions, the rule checks that the "time since event" on a particular power-reporting plug is less than 60 minutes. If it isn't, the rule sends a notification. In practice, "time since event" never goes over 60 minutes unless there is a power outage or failure of either plug or connected equipment.
Last night, during the second interval between 1:00 am and 2:00 am, after the clock was rolled back one hour, the rule fired a notification every 10 minutes.
DST change is a nightmare for code that has old and new times, or for that matter any code with time values in calculations. We've pounded our heads against this from the beginning of the company, and at this point I'm ready to quit fighting it. I'm happy to live in a state without DST at all, and can't wait for the rest of the states to get out of this disaster.
2 Likes
Is a hub reboot a good way to re-cage everything?
I was thinking of setting up a calendar reminder to just reboot each post-DST Sunday morning.
I understand. Not a big deal.
Not useful in this case.
I suppose ātime sinceā calculations could use Unix time to avoid all these issues but because RM allows specifying the difference in days, ambiguity would remain for days that cross DST changes.
Agree with Bruce itās not worth worrying about.
Ha, it does use Unix time (as does the scheduler) and the comparisons are done in seconds. So, go figure...
1 Like
