Hi Harlan, Look back in the archives for LSEM (Leap Second Every Month) discussions. The idea was to have a leap second at the end of every month, always. It would force all precision timing systems to correctly deal with leap seconds, positive as well as negative. DUT1 would remain < 0.7 s. By sheer annoyance it would force the automation of the leap second notification infrastructure. A past record or future scheduling of leap seconds could be encoded into as little as 12-bits per year.
LSEM would elevate leap seconds from unpredictable and rare to certain and common. Errors in software would be found within a month or two instead of many years. It would get rid of the awkward June/December convention, and track impending changes in Earth rotation 6x better. The next generation of school children would all know about leap seconds just like all children already know about leap years. It is compatible with WWVB and GPS and NTP and smearing algorithms. It would also solve a serious problem with UTC clocks today: not knowing if there is a leap second vs. knowing there is no leap second. The two states are currently indistinguishable but LSEM would allow you to know the difference. It replaces two unknowns (when is the next leap second and what sign will it be) with one unknown (what sign will it be this month). Of course the cost of LSEM would be prohibitive, but it's still an elegant idea on paper. /tvb ----- Original Message ----- From: "Harlan Stenn" <st...@ntp.org> To: "Leap Second Discussion List" <leapsecs@leapsecond.com> Sent: Saturday, August 29, 2015 12:49 PM Subject: Re: [LEAPSECS] countdown to WRC-15 > I've not been able to follow these discussions. I look forward to the > time when there's less pressure on my schedule. > > Has anybody put forth the following position: > > - The various current popular timescales are of significant value. > > - (a variety of points covering the "backstory", "foundation", and > pros/cons of these timescales.) > > - If something doesn't happen "often enough" it's difficult for people > who have to deal with these events to easily accomodate them. As a > case in point, I offer full/proper handling of leap years in > calendars. I submit this situation was not properly handled until 1) > the internet made it easy to copy/paste code, and 2) Y2K got everybody > looking at their date code. > > - So I propose that every N months' time, where N is 1-6, we schedule > either an addition or a deletion of a leap second. In doing so, we > make it "compelling" for leap seconds to be properly handled, and I > submit that the "problem" of handling leap seconds will be resolved > satisfactorily within 1-2 years' time. > > Are there significant additional costs to implementing this approach > when compared to the costs of continuing to only address leap seconds as > needed? > > I'm hesitant to have asked that, as it's akin to asking what the costs > are to changing UTC so it doesn't have leap seconds. This is all about > "how to lie with statistics", except that the scope is much smaller. > > I'll point out that a side issue is that there are HUGE number of > ancient versions of NTP out there and too many folks are being slow to > update. Dealing with leap second additions and deletions will be yet > another incentive to upgrade this software. > > -- > Harlan Stenn <st...@ntp.org> > http://networktimefoundation.org - be a member! > _______________________________________________ > LEAPSECS mailing list > LEAPSECS@leapsecond.com > https://pairlist6.pair.net/mailman/listinfo/leapsecs _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
