[LEAPSECS] A leap second proposal to consider -- LSEM

Tom Van Baak tvb at LeapSecond.com
Wed Nov 3 01:15:40 EDT 2010


I was working on a synthesizer project recently. Some of you
know about dual-modulus frequency dividers. Anyway, here's
an idea that came out of that.

(1)
We know the astronomical community depends on UT1 for
terrestrial telescope applications. They use UTC instead of
UT0 or UT1 because UTC is available just about everywhere
and (by design) UTC has been close enough to UT1 for most
telescopes. Note that for precision applications DUT1 can be
obtained in real time from IERS (to sub-millisecond levels).

It's probably safe to say the closer UTC is to UT1 the happier
the astronomer camp will be.

(2)
There are a number of challenges that leap seconds create
for the metrology/computer/networking/scientific/business
community. One is the existence of a highly exceptional time
stamp with ":59:60" in it. Another is that precise or autonomous
clocks must be in touch with some "mother ship" a few times
a year in order to know if or when the next leap second is.

Likewise any software that deals with the past must have or
obtain or maintain a historical table of leap seconds. The rare
insertion of one second in an otherwise linear time scale
forces some applications to create shadow, non-leap time
scales. And then there's the issue of negative leap seconds,
which get even less testing than positive leap seconds.

But the main problem is that leap seconds are unpredictable.
Moreover they are increasingly rare compared to software
life-cycles. Thus systems level testing of real-life leap seconds
ranges from difficult to near impossible.

Leap seconds are so weird and unusual that time-nuts collect
them, newspapers write articles about them when they show
up every few years, and technologists worry about them.

It's probably safe to say the more predictable leap seconds
are the happier the technology camp will be.

(3)
What would happen if instead of getting rid of leap seconds
we had *more* of them? So many more that all software just
had to implement them. And so often that products would
have a plenty of chances to be "leap second qualified" before
release; tested with both positive and negative leap seconds.

An event is no longer weird if it happens all the time. Easy to
understand, frequent, periodic events get tested, get trusted,
and reliable infrastructure gets built to support it if necessary.

So how about having a Leap Second Every Month (LSEM)?

The definition of UTC doesn't even need to be changed. The
only question for the IERS each month is if the leap will be
positive or negative. But there is always a leap; with one or
many months of notice. It's only 12-bits of data a year. This
can be disseminated in a modern way (internet).

No secular drift. No religious objections. No redefinition of
UTC. No change to WWVB. No change to GPS. No change
to NTP. No more silly leap second newspapers articles. Way
more opportunities for software to be written correctly the
first time. Wider public knowledge and understanding of leap
seconds. The impetus for creating well-architected internet
leap second information services. Closer tracking of UT1.
Greater ability to handle unusual earth accel/deceleration
episodes.

Astronomers should love this since it keeps UTC even closer
to UT1 than what they have today.

And for everyone else, it removes uncertainty of leap seconds.
Any software needing precision time will have to deal with leap
seconds. And there is far more opportunity for getting it right
because they will occur so regularly and so often, positive and
negative. There are no more exceptional events.

OK, I know there are some problems with this. But it's a viable
alternative to existing proposals; if nothing else a little diversion
from the ruts the community has dug itself in.

/tvb
www.LeapSecond.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20101102/c014d632/attachment.htm>


More information about the LEAPSECS mailing list