Time is an illusion, Unix time doubly so

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.

Yes but bringing down a database should not be among those things.

Surely we can agree on that.

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.

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 should be a steady heartbeat counting up the number of seconds since ...

This is nice and clean, so long as you have exactly one computer. The second there are more than one, and they are talking to each other, their clocks can go out of sync with each other. And they will, because they are physical systems that are imperfect and in general much less precise than you'd expect them to be.

This means that there has to be a way to correct for errors. The best method, that almost everyone who manages a lot of computers converges onto, is to "smear out" any errors, by never discretely changing the time on any machine, but just shortening or lengthening seconds slightly to bring any outliers back to the correct values. And once you have this system, dealing with a leap second using it is the easiest, simplest and least errorprone method.

I do think that there are purposes where local "machine time", which is just a monotonic clock counting upwards from bootup, would make sense. Especially when subsecond accuracy is important. But it should always be clear that there is no way to reliably convert between that and wallclock or calendar time. There are *no* intervals of calendar/wallclock time that reliably convert to any interval of machine time. It is not guaranteed that any wallclock minute contains exactly 60 machine seconds.