Hi Tom, > Does your proposal allow for a Zero leap second
Nope, LSEM avoids the zero leap second situation. That's the idea: to always have a leap second. Either an add or a delete, at the end of every month. The beauty is that it wouldn't violate how UTC is already defined. Leap seconds would become a monthly normal instead of a rare event; that is, a regular pain in the ass instead of an exceptional pain in the ass [1]. Note that UTC would continue to stay within a second of UT1, so no problems there either. If you think about it, LSEM, like any fast dithering system, would actually create a better average value of UT1 than the existing slow step system. But that's not a goal; just a PWM side-effect. There's more info in the original LSEM proposal and its long thread in the archives: http://six.pairlist.net/pipermail/leapsecs/2010-November/001813.html > Might also cause less consternation for some services, like the finance and > scientific worlds, that seem to have critical issues when an LS appears. add to your list: airplanes, high-speed trains, telesurgery, self-driving cars, MRI machines ... Yes, and that's the key question. And it's only getting worse. LSEM is not a random idea or a quick fix. As long as UTC has leap seconds (debatable) or as long as technology continues to depend on ever more precise time (likely) we have to make the handling of leap seconds as robust as the handling of, say, midnight rollover. I realize it's probably too late in history to deploy. There's no right answer. LSEM is food for thought. Lots of people are and have been trying to avoid the long-term train wreck that the current definition and implementation of UTC will lead to. If you have time, read 15 years of our postings over on the leap second mailing list. I think at this point, we should move the thread over to LEAPSECS alone, and give time-nuts a break. The cross-posting is getting confusing. Thanks, /tvb [1] astronomical society specification ;-) ----- Original Message ----- From: "Tom Holmes" <[email protected]> To: "'Discussion of precise time and frequency measurement'" <[email protected]> Cc: "'Leap Second Discussion List'" <[email protected]> Sent: Thursday, July 21, 2016 12:03 PM Subject: Re: [time-nuts] Leap second to be introduced at midnightUTC December 31 this year > Hi Tom... > > Does your proposal allow for a Zero leap second, or does it require either > plus or minus 1 to work? Seems like you could stay closer to the true value > if you also have a zero option. Might also cause less consternation for some > services, like the finance and scientific worlds, that seem to have critical > issues when an LS appears. > > I like your point that by having it occur monthly it forces systems to > address issues promptly, and maybe that's the argument for the non-zero > option. > > Tom Holmes, N8ZM > > > -----Original Message----- > From: time-nuts [mailto:[email protected]] On Behalf Of Tom Van Baak > Sent: Thursday, July 21, 2016 1:28 PM > To: Discussion of precise time and frequency measurement <[email protected]> > Cc: Leap Second Discussion List <[email protected]> > Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC > December 31 this year > > Time to mention this again... > > If we adopted the LSEM (Leap Second Every Month) model then none of this > would be a problem. The idea is not to decide *if* there will be leap second, > but to force every month to have a leap second. The IERS decision is then > what the *sign* of the leap second should be this month. > > Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, > not so much by rare steps but by dithering. There would be no change to UTC > or timing infrastructure because the definition of UTC already allows for > positive or negative leap seconds in any given month. > > Every UTC-aware device would 1) know how to reliably insert or delete a leap > second, because bugs would be found by developers within a month or two, not > by end-users years or decades in the future, and 2) every UTC-aware device > would have an often tested direct or indirect path to IERS to know what the > sign of the leap second will be for the current month. > > The leap second would then become a normal part of UTC, a regular monthly > event, instead of a rare, newsworthy exception. None of the weird bugs we > continue to see year after year in leap second handling by NTP and OS's and > GPS receiver firmware would occur. > > Historical leap second tables would consist of little more than 12 bits per > year. > > Moreover, in the next decade or two or three, if we slide into an era where > average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a > day, there will be zero impact if LSEM is already in place. > > /tvb > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
