Mass media article on leap seconds

[Alex]

On Wednesday, Mar 3, 2004, at 03:17 Australia/Sydney, Markus Kuhn wrote:

> 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.

That would destroy the constant (plus of minus a fraction of a second) 
relationship between a maintained timescale and mean solar time at a 
given longitude. I could no longer look at a map (with longitude lines) 
and know immediately what local mean solar time is (just about exactly, 
at least where the longitude lines are). That would be sad, if nothing 
else.

>> 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.

Hear, hear! Bravo!

> 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.

1: Stop time distribution services from providing UTC and get them 
providing TAI instead.
2: Estimate and publish leap-second dates 30, 40, or 50 years in 
advance, thus maintaining a table of offsets for that many years into 
the future at all times. Poor estimates could be corrected later. The 
only casualty of this would be the sub-second difference between UTC 
and UT1 (or whichever it is). Yes, my quick inference of mean solar 
time from longitude would be slightly less accurate. And software will 
need to be updated anyway; lead time could be decades.

> 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.

See 2 above. The calendar could also be the subject of similar 
treatment, substituting leap seconds with leap days and years (in 
advance) with centuries or millennia.

Alex LIVINGSTON