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

[Tom Van Baak]

Hi Rob,

Thanks for that link (and thanks to Steve for the old USNO
archive).

The key point of LSEM is that 100% of the months would
have leap seconds, not 80% as in Ed's email. If that means
DUT1 gets closer to 1.0 instead of 0.9 so be it. In his and
in today's leap second implementation there are still two
questions: 1) will there be a leap second this month (or
semi-year or quarter-year), and 2) what sign will it be.

This results in some months of some years being special,
which is what I was trying to avoid. 0% or 100% avoids
special cases. A proposal to eliminate leap seconds will
create certainty by going to 0%. The Leap Second Every
Month proposal creates certainty by going to 100%.

LSEM eliminates question 1. Everyone will know there is
a leap second at the end of every month. IERS just picks
the sign for us. And yes, like Ed observed, mostly it will
be a string of alternating pluses and minuses.

A desirable side-effect of LSEM is -- one now has a way
to determine if a clock has been "armed" for the next leap
second.  Today, for example, in many systems there is
no visible difference between not knowing if a leap second
has been scheduled from knowing that no leap second has
been scheduled. (re-read that sentence if necessary).

This situation seems a little dangerous to me. With LSEM,
if a clock has no leap second scheduled it means it still
needs its monthly sign bit from the IERS. It has until the
end of the month to get it from a reliable source.

So you end up with three kinds of clocks:

1) Common clocks where 1 second accuracy is sufficient
and leap seconds are never used. These count 86400
seconds a day, every day. The assumption is that they are
less accurate than 1 second a day or even 1 second a
month (approx 0.4 ppm) and are in the habit of being rate
disciplined or time sync'd by a higher authority.

2a) Precision clocks, where the sign of the leap second is
still not known. That is -- Warning: you have until the end
of the month to fix this.

2b) Precision clocks which have been network-automatically
or manually set with the sign of the next leap second and are
good to go until next month. The last day of every month will
always have 86399 or 86401 seconds and never 86400.

I probably don't have to point out that this "dithering" method
neatly reflects rather than rejects the fact that the earth is a
relatively unstable clock. The newcomers to the list may enjoy:
    http://www.leapsecond.com/museum/earth/

/tvb

----- Original Message ----- 
From: "Rob Seaman" <seaman at noao.edu>
To: "Leap Second Discussion List" <leapsecs at leapsecond.com>
Sent: Tuesday, November 02, 2010 11:06 PM
Subject: Re: [LEAPSECS] A leap second proposal to consider -- LSEM



> On Nov 2, 2010, at 10:15 PM, Tom Van Baak wrote:

>

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

>

> By all means - something to consider...

>

> ...which we've done before, e.g., in August 2003:

>

> http://www.ucolick.org/~sla/navyls/0197.html

>

> Variations of positive/negative scheduling came up at other points, but I haven't figured out how to search the zombie 

> Navy archives.

>

> The fundamental idea, well stated in Tom's message, is to embrace the requirement rather than run from it.  This is 

> good advice when architecting anything.

>

> Rob

>

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>