Anyway, kill the DST with fire.
Only if we don't move to permanent summer time.
The 1 Hour per Year Bug, but only in Pacific time
61–65 of 65 posts
Re: The 1 Hour per Year Bug, but only in Pacific time
#62Hey folks! I appreciate all the comments. Some of them made me realize I had some mistakes in the article. I went ahead and updated some of the content, and also added some notes explaining what I changed. Thanks for the feedback :)
Re: The 1 Hour per Year Bug, but only in Pacific time
#63My 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 A…
All 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.
A 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 :-)
Re: The 1 Hour per Year Bug, but only in Pacific time
#64Wow, that’s a tricky bug! Time zones can be so confusing. Glad you figured it out and fixed it. Do you think this could happen in other time zones too?
Re: The 1 Hour per Year Bug, but only in Pacific time
#65Earlier quoted context omitted.
All 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.
A 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 :-)
I'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.