Mass media article on leap seconds

[Markus Kuhn]

"Olson, Arthur David (NIH/NCI)" wrote on 2004-03-02 14:38 UTC:
> The 2004-03 issue of the U.S. monthly "Discover" has an article titled "Leap
> Seconds" by Karen Wright(pages 42-45, but the first two pages are décor and
> an introductory blurb).

Links to 10 further recent mass-media articles on the leap second are
collected at the end of

  http://www.cl.cam.ac.uk/~mgk25/time/leap/

> also notes a couple of modest proposals: "Leap seconds could be inserted
> every four years along with the February leap day...or leap minutes could be
> added every half century or so." (Either proposal, if adopted, would require
> changes in both POSIX and the public-domain time zone code.)

In the ITU SRG 7A group that currently deliberates the future of UTC,
these proposal have already been rejected as being impractical, more
than a year ago. The only proposal left on the table is to drop leap
seconds forever. This would detach the international reference time
(currently called UTC) from the rotation of the Earth. The point where
the new international reference time [the proposal calls it Temps
International (TI)] would correspond to local mean solar time would very
slowly accelerate eastwards, starting from Greenwich. One specific
proposal is to replace UTC with TI in 2022 (50th birthday of UTC). At
that time, UTC and TI will be identical, but TI will be a physical (that
is based on the SI second, not on the angle of the Earth) time without
leap seconds. TI is just TAI plus an offset for smooth transition in
2022. Local civilian times would be defined relative to TI, which takes
over this role from UTC. UTC would no longer be maintained. Their TI
offset of local civilian time zones would have to change every couple of
hundred years to keep local civilian times in +/-1 h sync with daylight,
but as well all know, local civilian times change far more frequently
for political reasons anyway. These LCT changes could easily be
implemented by dropping the repeated hour at the end of summer time
every few hundred years (the first one in around 2600) in those time
zones that have it.

> Your correspondent's two cents: in setting up the time handling in UNIX, T&R
> got it exactly right with respect to springing forward and falling back when
> DST goes in to and out of effect--keep the computer counting monotonically
> and leave it to the software to translate the monotonic count into a
> representation of local time. What's right at the level of an hour is also
> right at the level of a second--keep the computer counting at one count per
> second, and leave it to software to figure out what should be displayed when
> the user asks what time it is.

I don't agree. There is the important difference that UTC is today very
widely disseminated, whereas TAI is a curiosity only known to time geeks
like us. Keeping a computer synched to something like TAI would only be
practical in the real world if a leap-free timescale (e.g., the existing
TAI or GPS time) were widely enough available, along with a regularly
updated UTC-TAI offset table. Current time distribution services,
however, provide only UTC in easily accessible form, therefore running
machines in TAI would likely cause them to get the leap second offsets
wrong due to out-of-date leap-second tables rather quickly. Their
timestamps would quickly get an integer number of seconds wrong relative
to the timestamps of machines with up-to-date leapsecond tables.

In the present scheme of how we define local civilian times (namely
relative to UTC), I believe that what POSIX does (namely making time_t
an encoding of what a UTC clock displays) is the most practical
compromise. It needs a bit fudging near a leap second but works reliably
the rest of the time, without a need to maintain long-term state
(leap-second tables). In case the TI proposal gets implemented, the
problem would be gone, and the only long-term problem would be that TI
and local times drift apart without limit in the long term. But it will
be several millenia before the difference even reaches a single day, at
which time the Gregorian calendar will have gone well beyond its
best-before-date as well. Tables like tzdata with offsets between the
international reference time and the LCTs would have to be maintained
and updated in either case, but they are, in most parts of the world,
much more stable than leap second tables.

Markus

-- 
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__