Re: [LEAPSECS] The real problem with leap seconds

From: Tim Shepard <shep_at_ALUM.MIT.EDU>
Date: Wed, 11 Jan 2006 00:08:35 -0500

> > I still think NTP should have distribute TAI, but I understand using
>
> Was your failure to form a past-participle a Freudian slip? I'm with you
> if you really mean "NTP should distribute TAI"!!!

Uh, probably yes. I didn't even see the grammer error when I re-read
it the first time just now.


About 15 years ago I came to believe that it would have been better if
NTP distributed TAI instead of (or perhaps alongside) UTC.

And yes, I still believe that.

Now I think it would be best if TAI and UTC were both distributed by
time signals (and NTP, etc), with equal emphasis to make it clear to
all users that they have a choice to make.

Atomic time based on the SI second (TAI) and traditional time based on
earth orientation (UT) are both needed in the modern world. Both
should be distributed. People who have some need to synchronize
clocks should be forced to decide which kind of time would be best for
them. (Or perhaps in some cases it would be best for them to
implement both side-by-side in their system.)

A system which distributes TAI (which never has leap seconds) and also
distributes the current number of seconds of offset for UTC, as well
as leap warnings (or continuously broadcasts the table of all known
(past and scheduled) leap seconds), would seem to be reasonable.

This would allow the decisions about what would be the best time scale
to use to be made downstream. Build good mechanisms that allow a
variety of policies, and leave policies to those downstream of you.

My preference would be for civil time keeping to continue to be tied
to earth orientation, as it was when GMT was the standard. So UT1 or
UTC would continue to be "normal" time, and TAI (or something like it)
would be the "weird" time that certain geeks care about.

The other alternative would be for civil timekeeping to be based on
TAI (something which never has leap seconds), with UTC (or something
like it) to be the "weird" time that certain geeks care about. This
is the radical proposal, but I can understand that some would want to
do this.

If humans spread out to other places besides the earth, an
earth-centric time scale might begin to seem somewhat quaint.
Distributing leap second information to a Mars colony seems kind of
silly. (Though I guess that those on a Mars colony would in fact care
about earth orientation, e.g. if they wished to communicate with
friends back on Earth using their amateur laser-communication gear in
their backyards.)



I very much dislike the proposal to *redefine* UTC to abolish leap
seconds. I dislike very much trying to understand code that was
written with descriptive names (for variables, functions, constants,
etc) but which has evolved such that what the names apparently mean
and what they really mean are very different. UTC is a type of UT
time. If you stop putting leap seconds in UTC to keep it close to all
the other UT time scales, then it no longer deserves to have a name
that starts with UT.

So fine, if we must stop maintaining UTC with leap seconds and move
civil time keeping users to some sort of new standard, please do *not*
call it UTC after the change.


The hack of having UTC ticks align with TAI ticks and adjusting UTC
with leap seconds was perhaps not the best idea. But it was done, and
has been in place for more than 30 years, and is now a widely
implemented and understood standard. If this hack should be replaced
with something better (and perhaps it should be), I'd want 20 years
advance notice that a change is coming, and 15 years advance notice as
to what exactly the change will be. (I suspect though I won't get
that much notice.)

"leap hours" are a horrible idea, whether they be leap hours inserted
in to some UTC-like global standard, or by local jurisdictions.


Well, those are my opinions. Thanks for listening.

                        -Tim Shepard
                         shep_at_alum.mit.edu
Received on Tue Jan 10 2006 - 21:19:34 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT