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.
Every "day" has 86400 "seconds" (60*60*24).
There are no lookup tables of when leap seconds happen.
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
squelched astronomers who insisted that leap seconds would
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
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
While viewing this page see also:
Steve Allen <email@example.com>
$Id: picktwo.html,v 1.30 2017/07/14 18:23:36 sla Exp $