What harm does a leap second cause on a Unix system?

Question

RedHat gives a warning on its homepage:

A leap second event will occur on 2016 December 31, 23h 59m 60s UTC.

It's prefixed by an exclamation mark which seems to read important. What harm does a leap second cause on a system? How do we deal with it?

Answer 1

None whatsoever.

Leap seconds have been occurring since 1972, and Unix systems have been living through them quite unharmed for all of that time.

RedHat choosing, this time around, to splash an amber alert message across the top of its customer support WWW site is giving people quite the wrong impression, and causing people to think that it's something like a zero-day virus alert, and reacting in ways such as can be seen at Leap second Bug 31st Dec 2016 talking of a "leap second bug".

A leap second is not a bug, and Unix systems cope with them perfectly fine. The C library has for decades promoted the idea that the tm_sec field of a tm structure can sometimes have the value 60.

In fact, the only real problem is that Unix and Linux systems have a wide range of different ways of coping with them, according to taste. So one has to know what setup one has chosen, in order to know what actions, if any at all, one needs to take.

The RedHat page rather buries this under an extensive backgrounder, makes a bogus assumption about TAI-10 systems, and isn't the answer for a question that asks about Unices and Linux operating systems in general (albeit that it is a good answer for a worldview that is confined to RedHat Linux).

Fundamentally, you need the answer to three questions to know what you need to do:

• Is your kernel's clock running in UTC? Or in TAI-10?
• What are you using to synchronize your machine's clock with other systems?
• How do the other systems deal with the leap second?

Some cases of what to do

Your kernel clock is TAI-10 and the machine is synchronizing using a TAI-aware tool to TAI-10 servers

The synchronization tool will be something like Daniel J. Bernstein's taiclock, Laurent Bercot's s6-taiclock, or OpenBSD's rdate in its default TAI-10 mode.

You pretty much do not have to do anything in this scenario except ensure that your leap second tables are up to date. The kernel clock keeps on ticking at one SI second per second (corrections for oscillator drift and suchlike permitting), and the leap seconds tables handle the adjustments from TAI-10 to UTC.

There are two sets of tables to keep up to date:

• the ones in your right/ timezone files, which you keep up to date by ensuring that you have an up-to-date version of your timezone file package (whatever that is) on your system
• the ones used by Bernstein and others' toolsets, which are in /etc/leapsecs.dat

  M. Bernstein hasn't updated the leapsecs.dat at cr.yp.to, but I have published an updated leapsecs.dat that includes the 2016-12-31 23:59:60 UTC leap second, packaged in a leapsecs package.

Since the servers that you are synchronizing to speak TAI-10 as well, the seconds that they publish are aimed to be always one SI second long, too. There will be no stepping, slewing, or smearing by the servers speaking TAI-10. Everyone ticks constant-length SI seconds, and the leap second is only visible as an artifact of your C library.

Your kernel clock is TAI-10 and the machine is synchronizing using a TAI-aware tool to UTC servers

The synchronization tool will be something OpenBSD's rdate in its UTC mode.

Again you pretty much do not have to do anything in this scenario except ensure that your leap second tables are up to date, as in the previous scenario. Again the kernel clock keeps on ticking at one SI second per second.

The problem is that the servers do not.

• If they smear the leap second, then they have been reporting a slightly slowed time for most of the last day of the year. Your time synchronization tool has unnecessarily been adjusting TAI-10 to keep synchronized to this false UTC, ending up with TAI-10 anything up to a second behind when the leap second arrives. Immediately after the leap second, your synchronization tools will need to speed up the clock to catch up with the extra TAI-10 tick that they missed whilst they were synchronized to longer-than-an-SI-second UTC seconds, and system clock seconds will be shorter than an SI second for a while to compensate.
• If they slew the leap second, then they will be reporting a slightly ahead time for a short while into the first day of the new year. Your time synchronization tools will unnecessarily adjust TAI-10 to keep synchronized to this false UTC. Ironically, they'll start off with TAI-10 correct immediately at the leap second, and it will gradually drift away from correct during the following day and then back again later, as the time servers gradually slow down back to UTC whilst your synchronization tools simultaneously try to speed up TAI-10 to their false UTC time.
• If they step the leap second, they will simply not report a monotonically increasing time to you, but the leap second insertion done by your synchronization tools should actually calculate things correctly, except at the very moment of the leap second when the UTC report from the servers is ambiguous. They'll at least be ticking at the rate of one SI second per second, though, and TAI-10 will stay correct in the days before and after, and not wobble about unnecessarily trying to synchronize TAI-10 to a UTC time that is actually wrong.

So if you run with TAI-10, you tend to like UTC time servers that step leap seconds, because the other options actually cause your TAI-10 time to be synchronized to sped-up or slowed-down UTC unnecessarily, and lose its one SI second per second nature.

Your kernel clock is UTC and the machine is synchronizing using a UTC tool to UTC servers.

This case subdivides according to what the time servers, that you are synchronizing to, do.

• If they smear the leap second, then they have been reporting a slightly slowed time for most of the last day of the year. Your time synchronization tool will synchronize to that, and your clock will be behind the times for a day.
• If they slew the leap second, then they will be reporting a slightly ahead time for a short while into the first day of the new year. Your time synchronization tool will synchronize to that and your clock will be ahead of time for part of a day.
• If they step the leap second, they will simply not report a monotonically increasing time to you, and to your synchronization tools it will appear that the system clock suddenly overshot by a second and needs to be corrected. How they react will depend from how you have configured your synchronization tools.
  • They might simply step the system clock too, in which case your applications will see the time step backwards by a second.
  • They are more likely to slew the system clock, though; in which case your machine will tick seconds that are longer than an actual SI second for a while, and be ahead of time for part of a day.
• If they announce the leap second, which is just stepping with a warning that a step is coming, then they are passing over the decision as to what to do over to your synchronization tools.
  • They might simply step the system clock too, in which case your applications will see the time step backwards by a second.
  • They are more likely to slew or smear the system clock, though; in which case your machine will tick seconds that are longer than an actual SI second either for the preceding day or for the following day.

Consequences

In only one of the UTC-servers+UTC-machine cases will your machine's time be correct, the case where applications see the time go backwards, something that Unix applications do not like to see. In all of the other UTC-servers+UTC-machine cases your machine's time will be incorrect for up to a day.

In the TAI-10-servers+TAI-10-machine case, your machine's time will be correct throughout. And in one of the UTC-server+TAI-10-machine cases, the one where the server steps the time, your machine's time will also be correct throughout, unless it happens to do a poll right on the ambiguous UTC time.

The consequences of your machine's time being incorrect are at the application level. The operating system is fine with this. (Contrary to popular belief, POSIX actually allows for the system clock to be, possibly deliberately, wrong.) If you do things like bill people by the second, for example, your idea of how long a second is and of when each second occurs, is different from your customers' idea, for possibly two days. Your customers and you may not have chosen the same setup.

Then there's the possible problem of your choosing to synchronize with a mixed set of time servers, some of which slew UTC, some of which step UTC, and some of which smear UTC. Much hilarity ensues in this case, as you confuse the Hell out of your synchronization tools. There's much irony, too. The "dumb" synchronization tools cope with desynchronized time sources better than the "smart" ones that try to work out which time source is telling the right time. In this particular situation only the steppers are even telling the right time. Whereas the slewers and the smearers have contradictory ideas of what the wrong UTC time is.

A final dishonourable mention goes out to the Linux kernel, discussed on the RedHat page. Synchronization tools can choose to step the time themselves, or they can instruct the kernel to do it. As RedHat reports, there's a history of problems with this, from internal timing mechanisms in the kernel not working right to the machine freezing up.

Further reading

• https://unix.stackexchange.com/a/294715/5132
• https://unix.stackexchange.com/a/327403/5132
• https://askubuntu.com/questions/416417/