What is a leap second?

Because the earth’s rotation is gradually slowing, approximately every 18 months' time we need to add an “extra” second to the clock. We must account for this second to keep accurate time. Although one second doesn’t seem like a big deal, over time those seconds would add up. It’s best to handle a leap second when it occurs to keep time running smoothly.

How do we account for leap seconds?

The way things are done isn’t always the best way. But in reality, each choice about what to do with a leap second is a set of trade-offs.

The most common method to insert a leap second is to set the system clock back by one second at the same instant we increment the number of cumulative leap seconds. However, this is not an ideal method for handling a leap second because it’s very important that time only advances, and most software only considers the “time” and doesn’t pay attention to the number of leap seconds. It’s the combination of the “time” and the number of leap seconds that lets us know that “23:59:59.9 + 26 leap seconds” happens before “23:59:59.1 + 27 leap seconds”. This is critical for systems that must maintain ACID - Atomicity, Consistency Isolation, Durability. It is also very important in areas including financial trading, the timestamps on logs, some healthcare or medical devices, and industrial processes.

How important? It will be a surprise. In the world of network security, surprises are never good. It’s best to avoid surprises by preventing opportunities for them to develop. Do you have a valve that turns on for .05 seconds? Done the wrong way, during a leap second that valve would be open for 1.05 seconds, or about 20 times more “stuff” than you want.

Is there a better way? And what is leap smearing?

Yes! There is a better way! OK, better in many ways, and worse in some others. Meinberg has conducted testing of a method called “leap smearing” that Google first started using for the June 2015 leap second. Rather than accounting for the extra second instantly, by setting the clock back, leap smearing gradually introduces the extra second over an extended period of time. This is good because it applies the leap second smoothly, and “dumb” client systems or devices can easily follow the change. It’s bad because during the application of the leap smear, the clock is incorrect. If your system has legal requirements about time stamp accuracy, using a leap smear may not be a legally-acceptable choice.

Meinberg tested applying the leap smear over various periods of time. From as short as 2000 seconds (approximately 33 minutes) to as long as 24 hours.

Above you see the results of applying the leap smear over 2000 seconds. Only the client represented by the green line is able to adequately account for the leap second in this short period of time. The rest of the client’s servers behaved as if the leap smear weren’t applied at all.

Here, you see the results of leap smearing over the course of 24 hours. Clearly, the servers played much more nicely with this test. Every client involved in the test was able to account for the leap second without issue.

In addition to the 2000-second and 24-hour tests, 10-hour and two-hour tests were also run. You can read the full report here.

Is there an even better way?

Yes! There is an even better way! Network Time Foundation has been working on its General Timestamp API (GTSAPI), which is a new timestamp structure that comes with a programming library. The GTSAPI lets systems and applications use whatever timescale they want, and makes sure these timestamps can be “mapped” to a canonical, monotonic timescale. This means timestamps can be taken in local time, satellite time, broadcast TV time, or even Martian Standard Time (Coordinated Mars Time). The GTSAPI was specifically designed to handle many different ways to handle leap seconds. We’ll be talking about the GTSAPI in future posts, and the more (financial) support we can get for the GTSAPI, the sooner it will be available.