UTC helps store specific moments in time. Notably it does not solve for "dates" nor recurrence. Many of my hairs have been lost to third parties thinking they've created viable systems simply because they use UTC.

▲ adrian_b 3 days ago | parent | next [-]

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.

▲ hdgvhicv 3 days ago | parent | next [-]

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”

▲

layer8 3 days ago | parent [-]

Moreover, you don’t want the recorded local time to change just because the tz database is being updated.

	▲	hdgvhicv 2 days ago \| parent [-]
		In theory historic times wouldn’t change as t data would be updated before the change. In reality that’s not always the case.

▲ Hackbraten 3 days ago | parent | prev | next [-]

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.

▲ dqv 3 days ago | parent [-]

> 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 3 days ago | parent [-]

> 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 \| parent [-]
		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.

▲ 3 days ago | parent | prev [-]

[deleted]

▲ Terr_ 3 days ago | parent | prev [-]

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

▲ s20n 3 days ago | parent [-]

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.

	▲	WillDaSilva 3 days ago \| parent \| next [-]
		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.
	▲	dqv 3 days ago \| parent \| prev \| next [-]
		> 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)`
	▲	3 days ago \| parent \| prev [-]
		[deleted]