[friendzis]

> Timezones, leap seconds... all of that only matters when you're showing the user a date. For recording and calculations, it doesn't.

You cannot, by definition, tell how many Unix seconds later "third of may, 2025, at noon, local time" is - there is no way to convert future, local times to Unix times, because that "conversion code" is not fixed. Sure, we can reasonably expect that definition of time flow relationship to local time will not change for past dates, but one must expect these changes for times in the future.

[aumerle]

That's true regardless of how you choose to encode time and is a problem of local time zones not unix time.

[friendzis]

Not really. Generally, you can tell whether "fifth of November, at midnight, local time" is equal to `now` or not as long as you have reasonably accurate information what "local" means. This is a problem of time encoding, because we do define what midnight is, but keep relationship between it and seconds passed undefined as long as possible

[aumerle]

And you can do that when "now" is encoded as unix time as well, provided you know what local is. Although, encoding "now" is by definition pointless, since "now" changes with every instant.

[icehawk]

Is there a system that does allow you do to do this? I can't think of one that would.

Local time requires a time zone, times zones are defined in relation to UTC, and there is an unknown number of leap seconds between now and 3 May, 2025.

[friendzis]

Yes and no. The thing is that it is quite convenient to track time in computers with monotonic clocks, but it also turns out that humans do not define time markers based on monotonic clocks (when far future times are considered) and just from time to time [re]define relationship between time markers and monotonic clocks.

By definition you cannot unambiguously tell how many seconds in the future Christmas in a few years will be. However, it turns out that as long as you have the monotonic clock synced, time marker definitions up to date and have reasonably accurate understanding what local time means you can rather easily tell whether `now` is "christmas in 3 years, when defined at 123456789 Unix time".

We, humans, define time markers based on astronomical phenomena relative to this particular floating rock. A system based on time markers (calendar days, holidays, full moons, whatever) can represent human times, but is very inconvenient for computers, because they are not necessarily well-defined. I mean, 12345679 Unix time is well-defined in itself even if it is not well-defined in relation to real world while "2025 May 3rd at noon" is simply not well-defined today. Timekeeping is extremely weird.

This is a trade-off. Either you store computer consumable time markers (monotonic clock values), but have to do processing to figure out how they relate real-world markers, or you store real-world markers and have to do processing to figure out how they relate to the monotonic clock. Sans DST, the first one is much more ergonomic.

DST is pain, but turns out it is pain in both systems. If you have future time marker and there is DST adjustment between `now` and `then` you have the very same problem: you don't know whether DST adjustment was taken into account when creating the marker. Fun thing is that if you do control (or can infer) adjustments, both systems become very similar, but the current is much more ergonomic.