Comment by Hackbraten

2 days ago

I disagree. A stored value that was a future time value yesterday could become a past time value tomorrow. Keeping up with the invariant adds complexity because stored data would have to be migrated all the time.

That added complexity can be much worse than using zoned values for everything.

3 comments

Hackbraten

Reply
dqv  2 days ago

> A stored value that was a future time value yesterday could become a past time value tomorrow.

And that past time value can become a wrong time value if it was converted from a user's local time to UTC before a tzdata version change.

UTC only works for absolute time and accidentally works most of the time for wall time as perceived by humans. It's vaguely similar to how calculating money with floats accidentally works most of the time.

I don't want this scenario:

    2027-03-08 11:00AM (Local) -> 2027-03-08 2:00PM (UTC)

    (tzdata version changes)

    2027-03-08 10:00AM (Local) <- 2027-03-08 2:00PM (UTC)

In either case, you still have to do a migration: you need to convert your old UTC stamp to a new one that represents the correct local time, or with what the grandparent proposed, just having it stored in the local time and converting it close to the time it actually occurs.

But the UTC -> UTC conversion is worse. You have to figure out which timezones changed in the new tzdata version, convert them to the new UTC value, then update tzdata. Most libraries seem to only support one tzdata version at any given time, so this is way more complex to me than just having the wall time stored so that it can be converted to the correct UTC value at "decision time".

  • anonymars  2 days ago

    > just having the wall time stored so that it can be converted to the correct UTC value at "decision time"

    Well, this isn't unambiguous in all cases either unfortunately: 1:30 AM in Houston, TX (Central Time) on 3-Nov-2024 could be either 0630Z (Central Daylight Time) or 0730Z (Central Standard Time), since the clocks will have fallen back.

    • dqv  2 days ago

      Yes, but it's vastly less ambiguous: ambiguity for one day between 1:00AM - 3:00AM out of the year vs ambiguity for all future dates and times.

      Now you can prompt the user for their intent when the time change is known or expected. The ambiguity is now narrowed down to only the situations where the time change could not have been known in advance.