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.
You can easily "display future TAI timestamps using typical date notation".
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.
Unix time is not UTC-based. It counts the number of seconds passed since a certain point in time, which may be described as date and time expressed in any time zone you like. It just so happens that in UTC it is easiest to remember for a human what this point was, since you get a lot of zeroes at the end.
Edit: I’m not entirely correct here, as aside from UTC the time zone, there is also UTC the time standard. See below.
I stand corrected. As I’ve double-checked now, unfortunately “UTC” is ambiguous in that it may refer both to the time standard and the time zone. In this case one can say that Unix time is based on UTC the time standard, but not the time zone. Although given that in Unix time every day has the same number of seconds and instead the clock is sometimes slowed down, while in UTC there is an additional 61st second, can we truly say that it’s UTC-based? I’d say it’s its own standard derived from UTC. Maybe that’s being too pedantic.
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.