On Thursday, July 21, 2016, Michael Wouters <[email protected]> wrote:
> Apropos Bob's comments, the problem of ambiguous timestamps during a > leap second, at least with current operating systems, is only made > worse by more frequent leap seconds. > > Making critical systems run on a leap second free time scale like TAI, > for example, just shifts the problem to the interface between those > systems and the rest of the world. Admittedly, this interface may be > more tolerant of discrepancies. > > Leap seconds have gotta go. No leap seconds seems preferable to more frequent leap seconds. > > Cheers > Michael > > > On Fri, Jul 22, 2016 at 8:13 AM, Bob Stewart <[email protected] > <javascript:;>> wrote: > > But would it really solve your problems, Jim? The problem is > essentially that periodically, there are two different clock times that > represent the same moment in time. For telescopes, stock markets, spread > spectrum, time-based encryption, etc that's a big problem. Would it not be > better to separate out those entities that are more dependent on precision > sequence than on clock time and accept that they are just going to be > different? Yeah, the talking heads on CNBC and Bloomberg would gravely > announce that today's stock market was opening a second later, but so > what? At least there wouldn't be any more questions about exactly when > transaction X occurred. > > > > Bob > > ----------------------------------------------------------------- > > AE6RV.com > > > > GFS GPSDO list: > > groups.yahoo.com/neo/groups/GFS-GPSDOs/info > > > > From: Jim Palfreyman <[email protected] <javascript:;>> > > To: Discussion of precise time and frequency measurement < > [email protected] <javascript:;>> > > Sent: Thursday, July 21, 2016 4:38 PM > > Subject: Re: [time-nuts] LSEM (Leap Second Every Month) > > > > The idea is the same as my local telco and their main exchanges. > > > > Every month they walk up to the main circuit breaker and cut the power to > > the entire building. All the UPSs and diesel generators get tested in > anger. > > > > This leap second solution is the best I've heard so far. > > > > Personally I now hate leap seconds because it ruins many hours of my > > observations at the radio telescope - but if this was implemented it > would > > force the software problems to be fixed. > > > > > > Jim Palfreyman > > > > > > On 22 July 2016 at 06:01, Brooke Clarke <[email protected] > <javascript:;>> wrote: > > > >> Hi Tom: > >> > >> I like this idea. I addresses the lesson from Y2K that something done > >> often works much better than something done only occasionally. > >> That's way you see the firetruck at the local store, because it's used > all > >> the time and so is more likely to work when needed. > >> > >> -- > >> Have Fun, > >> > >> Brooke Clarke > >> http://www.PRC68.com > >> http://www.end2partygovernment.com/2012Issues.html > >> The lesser of evils is still evil. > >> > >> -------- Original Message -------- > >> > >>> 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] <javascript:;>] On > Behalf Of Tom Van > >>> Baak > >>> Sent: Thursday, July 21, 2016 1:28 PM > >>> To: Discussion of precise time and frequency measurement < > >>> [email protected] <javascript:;>> > >>> Cc: Leap Second Discussion List <[email protected] > <javascript:;>> > >>> 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] <javascript:;> > >>> To unsubscribe, go to > >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >>> and follow the instructions there. > >>> > >>> _______________________________________________ > >>> time-nuts mailing list -- [email protected] <javascript:;> > >>> To unsubscribe, go to > >>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >>> and follow the instructions there. > >>> > >>> > >> _______________________________________________ > >> time-nuts mailing list -- [email protected] <javascript:;> > >> To unsubscribe, go to > >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > >> and follow the instructions there. > >> > > _______________________________________________ > > time-nuts mailing list -- [email protected] <javascript:;> > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > > > > > > > > _______________________________________________ > > time-nuts mailing list -- [email protected] <javascript:;> > > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- [email protected] <javascript:;> > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > -- Michael Rothwell [email protected] (828) 649-ROTH _______________________________________________ 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.
