The problem with the timer bug is that sios’ program will probably be waiting for x hours when the system time rolls over, and timer will suddenly show it has been running for negative 5+ days, so timer will not trigger after x hours and program will appear hung.
His program could check for negative timer value and either assume x hours have passed, or restart x hour timer depending on which causes less grief for his application (once a week your action runs twice with <x hour delay, or once a week it waits up to 2x time before performing action).
Fixing the timer node would be the best option. The quick fix is to update lastUpdateTime, but not output_OUT if dtSeconds is negative. This causes its own problems, but affect would be minimal for short UPD periods.