Excerpt From A Deepness in the Sky by Vernor Vinge
Unix time is UTC based, so it ignores leap seconds and deviates from how many seconds actually passed since the start of the epoch.
The actual number of seconds passed corresponds to TAI, but you can't convert future timestamps from TAI to UTC since you can't predict leap seconds, so you can't display future TAI timestamps using typical date notation.
> For recording and calculations, it doesn't.
Depends on what you're recording and calculating. Storing a UTC timestamp generally works when recording an event that already happened.
But it doesn't work for scheduling events like meetings, since there the authoritative time is often local time. If you simply store such future events in UTC you'll run into problems when the definition of the relevant timezone changes.
Edit: I’m not entirely correct here, as aside from UTC the time zone, there is also UTC the time standard. See below.
Both past timestamps and future timestamps are not exact numbers, but approximate numbers, affected by errors.
The only difference between past timestamps and future timestamps that are converted from TAI to UTC is in the magnitude of the errors.
If the past timestamps have been acquired on a computer whose clock had been synchronized by NTP, then the errors are likely to be less than 10 millisecond.
If the past timestamps have been acquired on a computer whose clock had not been synchronized with a precise source, then the errors are likely to be greater than a second and they may be as large as of several minutes.
For future timestamps, the uncertainty of the value of the difference between TAI and UTC makes the likely value of the errors to be of several seconds, and increasing with the distance of the timestamp in the future.
In conclusion, one must be aware of the probable magnitude of the errors affecting an UTC timestamp, but that does not prevent conversions between TAI and UTC, whenever that is desired.
One of the greatest mistakes when dealing with time values is handling them like they were exact values, which they are not.
To handle future timestamps with minimal errors, it is necessary to have 2 distinct data types, a TAI time expressed as a number of some time units, e.g. nanoseconds, and an UTC time that is a structure containing date and time of the day. An UTC time must never be expressed as a number of seconds from some past date. That is the huge mistake made by the "UNIX time".
Future timestamps must be stored using the appropriate data type, e.g. UTC time for a future scheduled meeting.
The hardware clocks and the low-level clock synchronization and handling programs should always use TAI time.
When the current time approaches a future UTC timestamp, the error of the estimation of the corresponding TAI time diminishes. The leap seconds are announced with many months in advance, so the correct TAI time for a future UTC timestamp will also be know with at least a few months in advance. There is no risk that you computer will fail to notify you about the right time of the meeting, except when a naive programmer handles the timestamps wrongly, which is unfortunately quite frequent.
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.
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.
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.