Programmers misconceptions about Unix time

I apologize to Patrick Mackenzie . Danny inquired

yesterday about curious facts about Unix time, and I recalled that sometimes it works completely unintuitively. These three facts seem to be extremely reasonable and logical, right?

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 exactly one second.
   
3. Unix time never moves backward.

All this is not true.

But it’s not enough just to say “All this is untrue” without explaining why . See below for an explanation. But if you want to think for yourself, do not scroll the clock!


Table clock of the 1770s. Compiled by John Leroux. From the Wellcome collection . Published under CC BY License

All three misconceptions have one reason: leap seconds . If you are not familiar with extra seconds, here is a quick reference:

UTC time is determined by two factors:

• International Atomic Time : Averaged readings of hundreds of atomic clocks around the world. We can measure a second by the electromagnetic properties of an atom, and this is the most accurate time measurement known to science.
  
• Universal time , based on the rotation of the Earth around its own axis. One full turn - one day.

The problem is that these two numbers do not always coincide. The rotation of the Earth is not consistent - it is gradually slowing down, so the day in Universal Time is getting longer. On the other hand, atomic clocks are devilishly accurate and constant for millions of years.

When two times fall out of synchron, a second is added or removed in UTC to restore synchronization. Since 1972, the IERS service (which runs this case) has added 27 extra seconds. The result was 27 days of UTC lasting 86,401 seconds. Theoretically, the appearance of a day lasting 86 399 seconds (minus one) is possible. Both options contradict the fundamental assumption of Unix time.

Unix time assumes that every day lasts exactly 86,400 seconds (60 × 60 × 24 = 86,400), without any extra seconds. If such a leap occurs, then Unix time either jumps after a second, or by counting two seconds in one. As of 2019, it is missing 27 leap seconds.

So our errors must 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, the Unix time will change exactly one second if the extra second has not been deleted .
  
  So far, in practice, seconds have never been removed (and a slowdown in the Earth’s rotation means that this is unlikely), but if it ever happened, it would mean that the UTC day was one second shorter. In this case, the last second of UTC (23:59:59) is discarded.
  
  Every Unix day has the same number of seconds, so the last Unix second of a 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, the Unix time advances two seconds UTC, and the Unix 101 timestamp is not assigned to anyone.
  
• Unix time can never go back until an extra second is added .
  
  This has already happened 27 times in practice. At the end of the day UTC add an additional second 23:59:60. Unix days have the same number of seconds, so it cannot add an extra second - instead, you have to repeat Unix timestamps for the last second. Here's what it looks like, in quarter-second intervals:
  
  
  
  If you start at 23: 59: 60.50 and wait half a second, the Unix time returns half a second, and the Unix 101 timestamp corresponds to two seconds UTC.

These are probably not the only oddities of Unix time — just what I remembered yesterday.

Time is a very strange thing.