Issues involved in computer time stamps and leap seconds

Three desirable characteristics for systems handling time

precise time (more so -- stable and precise frequency)
Elapsed time is based on an atomic frequency standard in a particular reference frame.
Every second that ticks is an SI second.
There are no "leap smears".
These are required for robust cell phones, GPS navigation, machine synchronization, financial market regulators, etc.
simplicity
Every "day" has 86400 "seconds" (60*60*24).
There are no lookup tables of when leap seconds happen.
calendar days
Days on the calendar are determined by the rotation of Earth.
This is the basis for the definition of Universal Time.

Of the above, a system can pick any two

precise time and calendar days
ITU-R TF.460 (originally CCIR recommendation 460)
CCIR chose this for radio broadcast time signals on 1970-02-03,
squelched astronomers who insisted that leap seconds would cause trouble,
and sold the leap second to the world as the perfect solution for all issues with time.
This choice made UTC the only time scale in which
the duration of one second and the duration of one day are defined and measured by different methods,
in which the clock is not related to the calendar.
Radio broadcast time signals implemented this on 1972-01-01.
During 1974-07 the 13th Plenary Assembly of CCIR named this time scale "Coordinated Universal Time (UTC)" in Rec. 460-1.
POSIX decided in 1988 that conforming systems MUST NOT use this time scale
(disregarding the existing implementation in the "right" time zone code).
calendar days and simplicity
Everyone had this understanding, that the clock is directly related to the calendar, since centuries before 1972.
POSIX (IEEE Std 1003.1-1988) chose this for computer time stamps
(disregarding advice about precise time, yet calling their computer time scale UTC).
Many other computer systems and languages chose this.
This is a Big Deal(TM) because contracts often specify that a vendor must supply a POSIX Conforming Implementation, but doing so means that a system trying to keep precise time cannot operate reliably during a leap second.
precise time and simplicity
Used in technical time scales (International Atomic Time (TAI), GPS system time, Galileo system time, BeiDou system time, Indian Regional Navigation Satellite System time, etc.) which are not concerned with calendar days.
Folks trying since 2001 to get ITU-R to abandon leap seconds in UTC have failed to achieve agreement for such a change.
Many governments have resisted a redefinition of calendar days as not being related to the rotation of Earth.
ITU-R WRC 2015 decided to retain leap seconds in UTC and defer action until 2023;
pundits believe this means ITU-R action is postponed until such time as external agencies forge agreement on the kind of time scale to be broadcast.

... somebody else's problem ...

The priorities chosen by each of the three groups above have been accompanied by lack of concern about the unhandled characteristic.

In 1970 when the CCIR decreed that leap seconds would start they had no algorithm for implementing them. It remains the case that the ITU-R has no responsibility for the ongoing implementation nor for any robust scheme of communicating the leap seconds to operational systems.

In 1988 when IEEE standardized POSIX they opined that computers do not keep precise time. Contrary to other cases where POSIX allows systems to implement a better scheme than required by the standard, in the case of leap seconds POSIX prohibits systems from doing the right thing.

The proposals to abandon leap seconds in UTC have not included text which describes the effect that would have on disconnecting the calendar from the rotation of the earth.

The documents from all of these groups have been silent about the issues that are not handled. Figuring out ways of handling the issues has been left as an exercise for other groups. The result has been that different systems have adopted different strategies.


While viewing this page see also:
Steve Allen <sla@ucolick.org>
$Id: picktwo.html,v 1.30 2017/07/14 18:23:36 sla Exp $