It's a similar painful insanity as: "Other currencies? Just convert them to US dollars on save, and store that number in the database, nice and easy, no problems."

This is a false analogy. Currencies are volatile whereas timezones are static and rule based.

Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.

Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.

Timezones were not historically static, and even today can change with little warning.

In U.S. states along the timezone boundaries, you’ll find situations where in the mid-20th century the timezone map of the state looks like a pepperoni pizza, and changed frequently. Reversibility is definitely not guaranteed.

> Converting timestamps between time zones is perfectly reversible while there is a loss of information when you convert a value to a new currency.

False. This scenario absolutely does happen:

    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)

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 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:

    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".

> 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.

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.

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.