Comment by adrian_b
2 days ago
UTC or TAI are the right solution for storing past time values. Any other information is superfluous and it makes things more complicated than they should be.
Future "time" values are typically not time values. Therefore they must be stored using a different more complex data type, which contains all the information that will be necessary in the future to determine the corresponding time value.
Using the same data type to store both past time values and future time values is in most cases a serious programming mistake, which either wastes resources or is likely to cause bugs.
I wouldn’t say local time is superfluous, as it gives context.
If a historic event occurred at 0300 on Feb 15th, there’s a significant amount of information in knowing the local time. Was it 3am in London, when most people would be asleep. Or was it 7pm Friday night In San Francisco when people were on Valentine's dates, or was it 3pm on Saturday afternoon when people were having a bbq.
If you were to write “the accident occurred at 0300 UTC” then that would imply something very different depending on what the local time was at the time.
How about “the shop opened at 9am every day, without fail”.
Far more useful than “the shop opened at 1600UTC for half the year and 1700UTC for the other half”
Moreover, you don’t want the recorded local time to change just because the tz database is being updated.
In theory historic times wouldn’t change as t data would be updated before the change.
In reality that’s not always the case.
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.
> 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:
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".
> 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.
1 reply →