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 specification of UTC-SLS is the file draft-kuhn-leapsecond-00.txt.
This proposal has now been published by the IETF as an Internet-Draft standard for wide discussion.
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:
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.
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.
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.
created 2005-12-14 – last modified 2006-01-18 – http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/