Misconceptions of programmers about Unix-time

My apologies to Patrick McKenzie .

Yesterday, Danny inquired about curious facts about Unix-time, and I remembered that sometimes it works completely unintuitively.

These three facts seem extremely reasonable and logical, aren'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, the Unix time will change by exactly one second.
   
3. Unix time never moves backwards.

All this is not true.

But it is not enough just to state “All this is not true,” without explaining why . See explanations below. But if you want to think for yourself, do not scroll the clock image!


Desk clock of the 1770s. Collected by John Leroux. From the Wellcome collection . Published under the CC BY license

All three misconceptions have one reason: leap seconds . If you are not familiar with the leap 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 measurement of time 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 match. The rotation of the Earth is not consistent - it gradually slows down, so the day in World time is getting longer. On the other hand, atomic clocks are devilishly accurate and constant over millions of years.

When two times fall out of sync, a second is added to or removed from UTC to return synchronization. Since 1972, the IERS service (which manages this case) has added 27 additional seconds. The result was 27 days UTC with a duration of 86,401 seconds. Theoretically, the appearance of a day of 86,399 seconds (minus one) is possible. Both options contradict the fundamental assumption about Unix-time.

Unix time assumes that each day lasts exactly 86,400 seconds (60 × 60 × 24 = 86,400), without any additional seconds. If such a jump occurs, the Unix time either jumps over in a second, or by counting two seconds in one. As of 2019, there are no 27 leap seconds in it.

So our delusions need to be added as follows:

• Unix time is the number of seconds since January 1, 1970 00:00:00 UTC minus leap seconds .
  
• If you wait for exactly one second, the Unix time will change by exactly one second if an extra second has not been deleted .
  
  So far, in practice, the seconds have never been removed (and a slower rotation of the earth means that this is unlikely), but if it ever happened, it would mean that the day UTC would be one second shorter. In this case, the last second of UTC (23:59:59) is discarded.
  
  On every day of Unix, 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 by two seconds UTC, and the Unix 101 time stamp 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 extra second 23:59:60. Unix days have the same number of seconds, so he cannot add an extra second — instead, he has to repeat the Unix timestamp 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 to half a second, and the Unix 101 timestamp corresponds to two seconds UTC.

This is probably not the only weird thing about Unix time - just what I remembered yesterday.

Time is a very strange thing.