UTC with Smoothed Leap Seconds (UTC-SLS)

Markus Kuhn

UTC-SLS is a proposed standard for handling UTC leap seconds in computer protocols, operating-system APIs, and standard libraries. It aims to free the vast majority of software developers from even having to know about leap seconds and to minimize the risk of leap-second triggered system malfunction.


The international standard timescale Coordinated Universal Time (UTC) is defined by a network of atomic clocks. It is kept synchronized with Earth's rotation through the occasional insertion and deletion of leap seconds. UTC is widely referenced in computer-related specifications, in particular communication protocols and application-program interfaces of operating systems. An increasing number of computer system is closely synchronized with UTC today. However, the specifications of these systems usually do not dictate an exact behavior of the system when a leap second is inserted or deleted from UTC, that is when UTC skips the last second (23:59:59) of a day or inserts an additional second (23:59:60). Some currently widely implemented methods for handling leap seconds are potentially disruptive.

The Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS) aims to solve this problem. It is a minor variation of the UTC time scale with the following properties:

The UTC-SLS specification provides a detailed explanation of the advantages of this particular choice among all the alternatives considered.


The detailed specification of UTC-SLS is the IETF Internet-Draft draft-kuhn-leapsecond-00.txt, January 2006.

Frequently asked questions

How widely was this proposal already discussed?

The UTC-SLS proposal was initially called UTS and was repeatedly discussed in various expert forums since 2000, including the USNO leapsecs mailing list, the USENET group comp.protocols.time.ntp, and the ITU-R SRG 7A Colloquium on the UTC timescale in May 2003 in Torino. Two earlier publications that described this proposal (then still called UTS) are:

What criticism has been voiced against this proposal?

The only specific criticism or suggestion for improvement that I ever heard in relation to this proposal concerned its original name, UTS, which has since changed (see below).

All other objections to UTC-SLS that I heard were not directed against its specific design choices, but against the (very well established) practice of using UTC at all in the applications that this proposal targets:

While these people are usually happy to agree that UTC-SLS is a sensible engineering solution as long as UTC remains the main time basis of distributed computing, they argue that this is just a workaround that will be obsolete once their grand vision of giving up UTC entirely has become true, and that it is therefore just an unwelcome distraction from their ultimate goal.

I do not believe that UTC in its present form is going to disappear any time soon. Therefore, it makes perfect sense to me to agree on a well-chosen guideline for how to use UTC in a practical and safe way in selected applications.

Why is UTS now called UTC-SLS?

The original October 2000 proposal was to call this specification UTS, for “Smoothed Coordinated Universal Time”. Daniel Gambis noted at the May 2003 Torino meeting that the IERS uses already internally a “Smoothed Universal Time (UTS)”, although he admitted that this term is not widely known. Nevertheless, his comment, combined with the idea that having the designation start with “UTC-” makes it perhaps slightly clearer to readers that UTC-SLS is just a minor modification of UTC, as opposed to yet another definition of Universal Time, changed my mind about the proposed name.

Why make UTC-SLS an IETF standard, rather than an ITU-R recommendation?

The definition of time scales has traditionally been the domain of astronomers and metrologists, and their respective international organizations (IAU, IERS, BIH, BIPM). The ITU-R got involved only with regard to time-signal radio stations, for which it defined UTC. The whole notion of a leap-second was born out of practical considerations to do with standard-frequency transmitters and their carrier-phase locked pulse-per-second time codes.

UTC has been adopted far more widely than just in radio time signals and radio clocks. It has become a standard reference in computer networking protocols, programming-language standards and operating-system interfaces. The question of how to deal with UTC leap seconds on computer networks arose primarily with the wide-spread implementation of NTP, a standard maintained today by the IETF. Since UTC-SLS is foremost an implementation and interoperability guideline for NTP users, the IETF seems the most appropriate forum.

In addition, the ITU-R working group in charge of UTC is at present busy discussing a proposal to abandon Universal Time entirely as the basis of civilian time keeping, in favor of a purely atomic-time based timescale that has no leap seconds. This proposal faces substantial opposition and it seems at present unlikely to go through. However, before that discussion is off the table, the working group is unlikely able to ponder more pragmatic recommendations on how to implement the existing UTC definition smoothly in systems other than radio clocks.

Is Google already using UTC-SLS?

In a sense, but not quite. In a September 2011 blog post, Google engineer Christopher Pascoe describes how Google internally distributes via NTP a "smeared" version of UTC that does not contain any leap seconds. This way, they avoid the headache of having to audit millions of lines of application code for how it deals with the potentially hazardous implementation of leap seconds in the existing Linux/etc. NTP kernel code. That simply jumps back by one second at the start of an inserted leap second 23:59:60, in other words it replays the 1000 ms worth of timestamps of the preceding second 23:59:59, and thereby makes time non-monotonic, which may cause malfunctions in application programs that depend on clock monotonicity.

Google's "leap smear" looks from an application writer's point of view very similar to UTC-SLS. However, their implementation differs in two important aspects:

Difference 1: Location of implementation

The UTC-SLS approach has the big advantage that NTP clients remain aware of the scheduled time of a leap second. This means that NTP clients can

With UTC-SLS, only application programs that do not worry about utmost levels of frequency stability are briefly lied to about UTC and thereby kept unaware of the leap seconds.

The Google approach mainly has the short-term practical advantage that no changes are needed to existing OS kernels. It is therefore easier and quicker to roll out locally with existing code. However, it violates the NTP protocol specification and therefore should really only be implemented in in-house networks that are isolated from the world-wide public network of low-stratum NTP servers.

Difference 2: Shape of smoothing

The choice of the much simpler linear correction function in UTC-SLS was motivated by the fact that it will be evaluated in the same code that applies already today time and frequency offset corrections when an application called gettimeofday(), and this is usually a linear function. Therefore, UTC-SLS can be implemented very efficiently, and very similar to existing kernel-clock PLL code, by just temporarily tweaking some of the kernel clock's internal parameters.

The semi-raised-cosine correction has the advantage of a smooth first derivative, and may therefore be easier to follow by some types of PLL. This makes sense if the correction is applied before any tracking kernel PLLs, as Google does in NTP servers. But it brings no advantage if the correction is applied after any PLLs. (A spline function formed by joining segments from two second or third order polynomials would have similar properties but is more efficient to evaluate in kernel-clock code, especially where floating-point registers are not easily available. So if there there really were a need for a smooth first derivative of the correction ramp, I'd advocate using a spline over a cosine.)

Overall, the Google experience suggests that there is a justifiable need for a smoothed version of UTC for use in computer APIs, if only for due diligence reasons. Their current solution makes sense because of its quick deployability in a highly heterogeneous environment. On the other hand, UTC-SLS has many additional advantages and remains a desirable and more robust candidate for a standardized, long-term solution for the same problem.

Markus Kuhn

created 2005-12-14 – last modified 2011-09-16 – http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/