As it Happened: Leap Second 37

At the end of 2016 timekeepers added an extra second to the time we use to track our everyday activities. This is needed to match the astronomical time, measured through the Earth’s slightly irregular rotation frequency, to the exact duration of a second defined through our atomic clocks. There are a number of ways for computers to handle this leap-second event. To see them in practice I configured four computers to record the event over the hours and seconds the adjustment took place. The results, which you can see in the video below, were very different from what I expected.

Three computers were running Debian GNU/Linux 8.6 (jessie) 3.16.0, and one was running the current release of FreeBSD 12.0. The computers marked with NTP were configured to synchronize their clocks with NTP (network time protocol) servers over the internet. These instruct them to add a second before midnight by repeating the Unix timestamp (seconds since 1970-01-01) of the last second. This is the number you see in the Unix row.

Because a second that is repeated with the same timestamp can be confusing, organizations such as Akamai, Amazon, Bloomberg, Google, and Microsoft implement a different strategy. They allow the leap second to be gradually introduced over many hours. For example, Google smears the time difference over twenty hours: half a second is added before midnight and half after midnight. The computer marked NTP Google was configured to use the time from time.google.com, which is supposed to implement this type of smear.

The computer marked TAI (Temps Atomique International) was configured to run on International Atomic Time. This non-standard configuration advances the Unix time over the leap seconds and then uses specially crafted time-zone files to display the correct time. This makes its timestamps, which in 2016 ran 26 seconds ahead of the standard Unix time, incompatible with other systems. For example, this difference will be a problem in file creation times and other timestamps stored in shared file systems, file archives, revision control systems, and databases. On this system the leap second appears as 23:59:60. Because its time is not automatically synchronized with NTP, you will see that its clock drifts as time goes by.

The leap second is inserted at the same time all over the world, at 23:59:59 UTC. In the video I show

• 12 hours before and after UTC midnight, recorded at one frame per minute. In these frames the SI row shows the time of a nearby non-Google NTP server.
• one minute before and after midnight recorded at 25 frames per second. Here the SI two shows seconds starting at 60 seconds before midnight, measured using the system’s raw CPU clock.

Two things in the video demonstrate things working as expected. (Jump to 1:33 in the video to see them.)

• The Linux NTP computer repeated second 1483228799 two times.
• The Linux TAI computer showed the time at TAI second 1483228826 as 23:59:60.

On two other counts, the results were quite different from what I expected.

• The Linux NTP Google computer, which was synchronizing with Google’s public NTP server, did not appear to smear time (compared to a non-smearing server). Furthermore, it repeated the leap second’s timestamp, although I was not expecting it to do so.
• The FreeBSD NTP computer did not repeat the leap second. Also, after the switchover the host’s time diverged from the time of its NTP server by two seconds, and the NTP client was (no longer?) running.

My take from this exercise is that the handling of the leap second is tricky and it requires thorough and difficult testing.

Notes

In retrospect I should have run on each host the command ntpq -c 'rv 0 leap' to query NTP on whether a leap second was announced to it.

I also attempted to record the leap second handling on a Microsoft Windows and a Mac OS X computer, but failed to get them work reliably by the end of the year.

The code I used to record the events and produce the animation is available on GitHub.

Comments   Toot! Tweet Share