3 ms·
DST being on a weekend doesn't mean things can't go wrong. If it's Friday at 1pm and you want to schedule something for 1 week later (next Friday at 1pm) and th
by burntsushi 2y ago
DST being on a weekend doesn't mean things can't go wrong. If it's Friday at 1pm and you want to schedule something for 1 week later (next Friday at 1pm) and there's a DST transition over the weekend, are you correctly getting next Friday at 1pm? Or is it 2pm because you didn't account for the jump forward in time, thus making this particular week 1 hour shorter than more?
DST problems can manifest in a lot of interesting ways. That's why it's important to use a datetime library that does DST safe arithmetic (like Temporal).
- lxgr 2y agoI didn’t mean to imply nothing could go wrong (and a lot does go wrong; I once watched a Windows PC freeze completely exactly at the time of DST shift!), but it does reduce the number of ways things can go wrong with non-defensive programming slightly. Not doing the shift on a weekday or the last of the month alone has probably prevented countless bank batch jobs from exploding.
- tjoff 2y agoCase in point. On the iphone in 2010, if you had a repeating alarm set before a DST transition it would go off an hour wrong. Sizable portion of society were late that Monday (most probably don't have repeating alarms on the weekend so I guess it went unnoticed for most). Best part. After making headlines all around, apple managed to have the same/similar bug next year.
- dexwiz 2y agoThis is an interesting question because it’s the difference between clocks and calendars. If you add 7 calendar days it’s 1pm. If you add 168 hours then it’s 2pm. Generally calendar systems will try to encode reasonable semantics for this on what a human would expect it to do. In those case it’s add 7 days. Calendars and clocks are not equivalent.
- burntsushi 2y agoYes, that's why I said "1 week." With time zones, units of days or higher are non-uniform.