4 ms·
My favorite DST bug was a system that was supposed to run every few seconds taking a nap for an hour. It was an event loop thingy that had a few different types
by yuliyp 2y ago
My favorite DST bug was a system that was supposed to run every few seconds taking a nap for an hour. It was an event loop thingy that had a few different types of tasks it might do. When it finished one of those tasks it'd record (in time-zone-local time) the time it completed it. When the event loop ran, it'd check that timestamp against now to see whether the task needed doing.
In comes the DST rollback. At 1:59 AM Pacific Daylight time the task ran. At 2:00 AM Pacific Daylight time the time changes to 1:00 AM Pacific Standard time. For the next hour it just sees "ooh 1:01 AM is not more than 1 minutes after 1:59 AM, I'm going to sleep. 1:02 AM is not more than 1 minute after 1:59 AM..." and ends up falling behind for that hour until it magically fixes itself at 2:01 AM Pacific Standard Time
- russdill 2y agoAll such delays should be done uses monotonic clocks. This simplistic solution runs still into problems when you have long delays, especially if the system suspends and/or power cycles. Or if you want the interval to always expire at some wall clock aligned time, such as every half hour on the half hour.
- yuliyp 2y agoA monotonic clock is a bit trickier when dealing with timestamps being written to / read from a separate database, but I agree with the sentiment. Hence why the chosen implementation was buggy :-)
- russdill 2y agoI've commonly seen a kick the can down the road type of solution to issues like these, especially in vehicle systems where a monotonic clock is always used but a entry is included that gives a mapping between wall clock and monotonic if it's available.