I agree that for many use cases the exact second is irrelevant, like submission times and things likes that. That being said, programmers do seem to expect, for example, that code like `(int)time(NULL) - previous_time` works and accurately gives the difference in time between now and whenever `previous_time` was given its value. This does work, but only 99.99% of the time. Then it breaks 0.01% of the time. For bug-free code it's important that the expectations of the programmer are in line with reality, and the problem with Unix time is that programmers' expectations of the mathematical properties of Unix time and the real mathematical properties of Unix time do not line up. This is what leads to the countless bugs involving leap seconds.

The fact that accuracy is often not important is also crucial to my proposal of legacy Unix time, because legacy Unix time would eventually go out of sync with the rotation of the Earth just like TAI. That said, in almost all cases this would practically be an aesthetic bug where dates in old user interfaces would be a few seconds off from the real date, and therefore not particularly harmful.

Timestamps are used for a lot of scheduling tasks that need to be reasonably precise. So an event happening one second earlier than expected, or even twice, could be a problem I suppose. Not exactly impossible to deal with, but I guess lots of people screw it up? Haven't really worked on systems where this _truly_ matters.

Synchronization between computers is hard. https://www.gnu.org/software/coreutils/manual/coreutils.html...

Could it matter for high-frequency trading? Since these trades occur in milliseconds, I presume trading being off by a second would be considered very damaging.

It is not just very damaging, it also has legal implications. For example MIFID II regulations require at least 100us resolution for trade reporting. In practice PTP and GPS clocks are a requirement.

Scheduling tasks on a system is done using UTC/local time which the system keeps accurate. Unix time is not used for that.

I am not aware of any operating system kernel that schedules tasks or timer expiration using a strict definition of UTC. Unix time is the most common, and local monotonic (non-decreasing) clocks are becoming common for that as well.

Of course there are application level schedulers that use wall clock time in UTC format, and if you set the clock back your task may run twice, which is a more serious real world problem than running twice around a leap second. That is why no one who is not attached to civil time should use UTC or Unix time for short duration timer expiration in particular.

That was my thought when considering the difficult and impossible tasks of converting to/from UTC-based timestamps. If we accept that UTC is only for human use then we should also accept that humans can't tell the time of day down to the second just based on their circadian rhythm and the Sun.

Given a TAI-based timestamp a hundred years in the future we can be pretty certain in saying "yeah it will be around lunch time" (assuming there is no major changes in the solar system that would probably have such an impact on the lives of every human that nobody would care about this event anyway).

But if you follow that argument then you might as well drop leap secnds from UTC (which also drops them from Unix time). Which is what was done. So computers can have nice math and conversions to UTC are not needlessly complicated for little benefit to humans.

For things like mission-critical logging, having time jump around, or even skew, is a real PITA.