Re: [LEAPSECS] Schreiver AFB warns about leapsec

From: Rob Seaman <seaman_at_noao.edu>
Date: Tue, 20 Dec 2005 10:42:23 -0700

On Dec 20, 2005, at 9:35 AM, Tom Van Baak wrote:

> Keeping to metric system conventions and following
> the humor of the above suggestion perhaps then leap
> milliseconds is the solution.

A bit more humor about these issues would certainly be welcomed by
all...but sorry, you won't get any from me.

> Then the instantaneous
> impact is only 1/1000th as much. By extrapolation
> one can consider microsecond leaps as well. At this
> level UTC becomes indistinguishable from UT1 and
> so the astronomers on the list will be happy. ;-)

Astronomers are among the more appreciative users of TAI as well as
UT1. It is nifty the way UTC manages to convey both.

> Another advantage with many more, but much smaller
> leap 'seconds, is that we'd finally experience negative
> leaps instead of just positive. With leap milliseconds
> occurring at the rate of more than one a day, software
> engineers would finally run out of excuses not to fully
> test their timekeeping code...

One of the more creative solutions suggested previously also has this
feature. Simply use the freedom of the current UTC specification to
schedule a leap second at the end of *every* month - first positive,
then negative, back-and-forth, to-and-fro. In that case an actual
leap second becomes the omission of an event. Look to the archives
for other possibilities at least as creative as leap tenths or leap
milliseconds. (One might also argue that frequent leaps become rate
changes in the limiting case.)

A benefit of discussing these options is that the current leap second
algorithm starts to look pretty tame by comparison.

> While you're at it let's change when leaps occur; not
> just at 23:59:59 but any time of day; carefully chosen
> so as not to repeat.

Our team schedules its afternoon pub meetings every 13 days rather
than every two weeks. That way the day of the week changes each time
to avoid issues like kids' violin lessons and volunteer hours and
such. Any non-random scheduling algorithm tends to recreate
unintentional patterns - say, like Lissajous figures when expressed
in 2-D. Leap seconds and leap days themselves are merely expressions
of the beat frequency between two periodic phenomena.

> Then the pseudo-random spread
> spectrum nature of this implementation will take care
> of Rob's world-wide business hours concern!

Recall that the original limp list of candidates for possible leap
second misbehavior included just two entries: GLONASS and "certain
spread-spectrum applications". I think this may be the first time
that term has been used in this discussion in the intervening half
dozen years.

Rob Seaman
National Optical Astronomy Observatory
Received on Tue Dec 20 2005 - 09:43:30 PST