Misconceptions programmers have about Unix time

Apologize Patrick McKenzie.

Yesterday Danny asked some interesting facts about Unix time, and I remembered that sometimes it works completely unintuitively.

These three facts seem eminently reasonable and logical, don't they?

1. Unix time is the number of seconds since January 1, 1970 00:00:00 UTC.
2. If you wait exactly one second, then Unix time will change by exactly one second.
3. Unix time never moves backwards.

All this is not true.

But it's not enough just to say "All this is not true" without explaining why. See explanation below. But if you want to think for yourself, don't scroll the clock!

Table clock from the 1770s. Collected by John Leroux. From Wellcome collections. Published under license CC BY

All three misconceptions have the same reason: leap seconds. If you're not familiar with leap seconds, here's a quick reference:

UTC time is determined by two factors:

• International atomic time: average readings of hundreds of atomic clocks around the world. We can measure the second by the electromagnetic properties of the atom, and this is the most accurate measurement of time known to science.
• Universal Timebased on the rotation of the earth around its own axis. One full turn is one day.

The problem is that these two numbers don't always match. The rotation of the Earth is not sequential - it gradually slows down, so the days in Universal Time become longer. On the other hand, atomic clocks are devilishly accurate and constant for millions of years.

When two times fall out of sync, a second is added or removed from UTC to bring it back into sync. Service since 1972 IERS (who manages this case) added 27 extra seconds. The result is 27 days UTC with a duration of 86 seconds. Theoretically, a day with a duration of 401 seconds (minus one) is possible. Both options contradict the fundamental assumption of Unix time.

Unix time assumes that each day is exactly 86 seconds long (400 × 60 × 60 = 24), with no extra seconds. If such a jump occurs, then Unix time either skips a second, or counts two seconds in one. As of 86, it is missing 400 leap seconds.

So our delusions need to be supplemented as follows:

• Unix time is the number of seconds since January 1, 1970 00:00:00 UTC minus leap seconds.
• If you wait exactly one second, Unix time will change by exactly one second, unless a leap second has been removed.

  So far, in practice, seconds have never been removed (and the slowing of the Earth's rotation means that this is unlikely), but if this ever happened, it would mean that the UTC day became one second shorter. In this case, the last second of UTC (23:59:59) is discarded.

  Each Unix day has the same number of seconds, so the last Unix second of the shortened day will not correspond to any UTC time. Here's what it looks like, in quarter-second intervals:

  
  
  If you start at 23:59:58:00 UTC and wait one second, Unix time will advance two seconds UTC, and Unix timestamp 101 will not be assigned to anyone.

• Unix time can never go back, until a leap second is added.

  This has already happened 27 times in practice. At the end of the UTC day, an extra second is added at 23:59:60. A Unix day has the same number of seconds, so it can't add an extra second - instead it has to repeat the Unix timestamps for the last second. Here's what it looks like, in quarter-second intervals:

  
  
  If we start at 23:59:60.50 and wait half a second, the Unix time back half a second, and the Unix timestamp 101 corresponds to two seconds UTC.

This is probably not the only oddity of Unix time, just what I remembered yesterday.

Time - very strange thing.

Source: habr.com