Re: [LEAPSECS] Leap second status?

From: Rob Seaman <seaman_at_NOAO.EDU>
Date: Wed, 4 Dec 2002 12:50:16 -0700

John Cowan says:

> When the solar day becomes four megaseconds [...] in length, we will
> look pretty silly continuing to claim that there are only 86,400
> "seconds" in it.

And how many billions of years hence? This hyperbole just reinforces
the false urgency being directed at this issue.

For the near term - and several thousand years after that - it is
hard to see humanity reaching a point at which it makes any sort of
sense - especially economic - to replace our current 24 hour clock.
(Imagine trying to convince your grandparents of the need to switch.)

More to the point, if we were to undertake the gargantuan task of
replacing one format clock with another - the new clock would face
exactly the same issue. Replacing the clock format doesn't fix the
problem. That's why this wasn't one of the options in the original
McCarthy and Klepczynski paper.

> No, no, the second is a fundamental unit of time duration. It must not
> be futzed with.

But redefining the duration of the second is a tool that we've previously
used for this task. However, that isn't precisely what I'm suggesting
should happen (many centuries hence). There is plenty of room for
compromise here. One possible scenario:

    - Retain the current unit as the "scientific second".
    - Wait until leap seconds are arriving almost every month.
    - Define a new unit, the "civil second", 1 part in ~3 million longer.
    - Leap seconds will now return to arriving once per year or so.
    - Only scientists and engineers will have to keep the two units straight.
    - Adjust the recipe and repeat as desired.

(I'm sure any errors in my arithmetic will be brought to my attention :-)

>> If they can't handle the current standard - why should we think they
>> will handle changes to that standard any better?
>
> It depends, obviously, on whether the changes are toward simplification
> or away from it.

"Simplification" is an interesting concept. Any changes must not only
simplify the description of the standard - they must simplify the
operational requirements. "Robustness" is another interesting concept.
To encourage robust system design, does one sweep technical realities
under the rug?

The notion of a leap second "freeze" is identical to implementing a
much larger tolerance on DUT. At some point, it is inevitable that
future members of this community will decide to resync GMT and UTC.
This is the same old trade of the latency between leap jumps with
the amplitude of the jumps. For the SRG to vote "to exclude from
consideration all redefinition options except freezing the number of
leap seconds" is misleading.

So - too frequent leap jumps are perceived to be a problem. If we're
ever going to issue leap jumps at all, so are too *infrequent* jumps.
Look at the "divisible by four hundred" rule for leap years. I know
of software that failed this test - don't you? Lengthening the gap
between leap jumps encourages lazy engineering.

The increased amplitude is also an issue. For most purposes, time
users (meaning "people") can ignore individual leap seconds. As has
been pointed out time and again - these events vanish in the imprecision
of the clocks in question. But people won't be quite so able to ignore
jumps of dozens or hundreds of seconds. And for technical purposes this
large a jump will be all the harder to swallow.

So both the increased latency and increased amplitude of the effect
magnify the difficulties. Unless we are *completely* certain that we
will never - never - think twice about freezing leap seconds, we should
find another solution.

My choice? Fully implement the current standard, such that - when it
eventually become necessary, many years hence - leap seconds are allowed
to occur at the end of every month, not just December and June. This
will keep the size of the jumps small - and will avoid lengthy separations
between the jumps such that hardware and software engineers will be
encouraged to address the *actual* technical tradeoffs.

Not new, not fancy - just the correct answer.

Rob
Received on Wed Dec 04 2002 - 12:04:23 PST