Unix time is bad and needs replacement, not UTC

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

Clocks are out of sync all the time, so any code that relies on precise timestamps needs some way to account for out-of-sync clocks anyway.

So if you store two timestamps, you can't rely that the actual time that has passed between storing the two timestamps is equal to their difference, since the clock might have been slow, fast, or might have been synchronised with another clock between the recording of the two timestamps.

I think dealing with leap seconds should work in a similar way as working with other clock synchronisation issues, so I really don't see the point of adding new types of clocks in unix.

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. 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.

EDIT: This comment was corrected by numerous replies below and the original comment contained incorrect information. Thanks to all posters for the corrections.

Original comment:

> The simplified definition of Unix time is that Unix time counts the amount of seconds that have passed since the first of January 1970 (which is referred to as “the epoch”, similar to the first of January of 1 AD being the epoch of the Gregorian calendar). This is of course not the complete definition, since it does not take leap seconds into consideration.

I disagree with the statement that UNIX time is not the amount of seconds since the Epoch. Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.

If we started an experiment on 23:00 and ended it on 01:00 the next day, but a leap second occured in the mean time, the experiment wasn't running for 7200 seconds, but for 7199 seconds. The leap second had nothing to do with time counting, a stopwatch would not add a second to the reading.

If we started an experiment on Epoch, the UNIX time tells us the amount of seconds this experiment has been running. If we added 86400 leap seconds in between, the experiment would count real time, not our made up time. One day wouldn't be added to the count.

As far as I understand it, that's what UNIX time is, and there's nothing wrong with that. It's a feature.

Please add your opinion.

The author is right. I couldn't believe it when I first learnt the difference between UTC and TAI that Unix time based on UTC. It makes no sense. And now they are talking about "correcting" UTC to make Unix time work? Thus defeating the entire point of UTC?

There's something about time that people seem to find very difficult to reason with. It reminds me of the arguments between whether we should use standard time all year or daylight savings time all year.