3 ms·

My favorite Date v Datetime bug is that Chile changes to DLS at midnight and not 1am. So it’s goes 11:59>1am. Many systems that conflate dates and date times ta

by dexwiz 2y ago

My favorite Date v Datetime bug is that Chile changes to DLS at midnight and not 1am. So it’s goes 11:59>1am. Many systems that conflate dates and date times take the existence of midnight as an invariant, which it is not.

lxgr 2y ago
Oh, that's another beautiful counterexample, thank you! I was wrecking my mind trying to come up with a scenario where what we did could go wrong with DST shifts alone (i.e. without a timezone conversion/relocation), but fortunately, most (all?) of Europe shifts DST on a weekend, never at the last day of the month, and with ample safety buffer from midnight, for which I am very thankful.
- wyclif 2y ago
  What kind of new projects will this new feature in ECMAScript enable? Just spitballing here.
- 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 ago
    I 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 ago
    Case 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 ago
    This 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 ago
      Yes, that's why I said "1 week." With time zones, units of days or higher are non-uniform.
- dexwiz 2y ago
  Another fun thing is that some countries that celebrate Ramadan may change back to normal time during Ramadan. So you can 2-4 DLS changes per year depending on when Ramadan falls. Luckily most time systems don’t really care, but it’s still a fun edge case. You really can’t hard code anything.

by dexwiz 2y ago

lxgr 2y ago

Oh, that's another beautiful counterexample, thank you! I was wrecking my mind trying to come up with a scenario where what we did could go wrong with DST shifts alone (i.e. without a timezone conversion/relocation), but fortunately, most (all?) of Europe shifts DST on a weekend, never at the last day of the month, and with ample safety buffer from midnight, for which I am very thankful.

wyclif 2y ago
What kind of new projects will this new feature in ECMAScript enable? Just spitballing here.
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 ago
  I 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 ago
  Case 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 ago
  This 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 ago
    Yes, that's why I said "1 week." With time zones, units of days or higher are non-uniform.
dexwiz 2y ago
Another fun thing is that some countries that celebrate Ramadan may change back to normal time during Ramadan. So you can 2-4 DLS changes per year depending on when Ramadan falls. Luckily most time systems don’t really care, but it’s still a fun edge case. You really can’t hard code anything.