[jesprenj]

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.

[account42]

Your understanding of Unix time is wrong. In your experiment the difference between the end and start Unix timestamps would be 7200 even though thats off from the experiment duration. That is exactly the problem: Unix time gets adjusted for leap seconds to stay in sync with UTC instead of real time.

[masklinn]

> As far as I understand it, that's what UNIX time is

Then you don’t understand Unix time. In the first case it would return 7200, and in the second case it would count “made up time”.

UNIX time is 86400*days since epoch + seconds since midnight. It does not measure “real time”, whatever that is.

> Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.

You’re apparently confusing leap seconds and DST. Leap seconds are used to compensate for minute variations in the speed at which the earth rotates (irregularities and an overall slowdown). So they serve to resynchronize atomic time (TAI) and solar time (UT1). This resynchronized version (UT1 ~ 1s) is UTC.

[zowie_vd]

In short, Unix time is based on UTC. If there's a leap second at midnight, you start a stopwatch ten seconds before midnight and stop it ten seconds after, then there is going to be a one second difference between your stopwatch and the difference between the Unix time timestamps of the moments you started and stopped the stopwatch.

[rand_flip_bit]

For the purposes of a stopwatch/timer, this is exactly what you want. A measurement of time that is exact and does not include leap seconds. Accounting for DST or leap seconds or any other changes to the local timezone for that matter would be disastrous. Imagine you are trying to bake a cake and the timer doesn’t go off for an extra hour due to the clocks getting set back. Now you just have a ruined cake :(

As far as Unix and UTC are concerned, many systems provide the option to smear the system clock over a 24h period (-12h, +12h) centered on the leap second. This avoids the discontinuity and can help avoid errors some incorrectly written programs may not be able to tolerate.

For leap smearing, see: https://developers.google.com/time/smear