Well, it is confirmed. Looping programs such as this are halted with a DST roll over, either one way or the other. Also, many time referencing programs will not be executed until the next midnight or later.

I have some service monitor programs that now look for any stopped looping programs, and force a restart, so a kind of workaround.

One can also force a system reboot, just after a DST roll over, but that is kludgy.

My question, is this bug logged/replicated by UD, and slated to be fixed at some point?

Thanks.

* Orest

Edited March 17, 20241 yr by oskrypuch

I do not use any looping timer programs without as many as four times each day that restart each program. In addition they all use the [Run at Startup] to restart them upon power failures or reboots.

DST time changes have been argued about here for almost a decade. There are many different types of cases where no one algorithm is not going to work.  I really doubt a complete solution will ever be offered.

Any  X minute loop programs will never execute any logic between 2:00 AM and 3:00 AM when the clocks move forward, be totally confused, and cannot offer a solution, that pleases all cases, when every minute between 2:00 AM to 2:59 AM occurs twice during the same night.

It would seem the only solution for automation programs using loop timing is to stop the governments from changing the clocks twice per year.

Well, (now) my service monitors will catch some of this, and the rest can be remedied by a forced reboot at 3:01AM when DST changes one way or the other.

But, my observation is that this has only started recently, as I moved from 994 to Polisy, and through the firmwares to 5.4.4 on one, and 5.8.0 on the other.

So, at some time in the past the system seemed more tolerant around the DST changes. Sure, my programming has changed in that time, but not dramatically. But, as I don't have better data than that (it is a hard thing to notice before you know it is going to happen), that observation is not going to be much help I expect.

* Orest