[time-nuts] LSEM (Leap Second Every Month)

Michael Wouters michaeljwouters at gmail.com
Thu Jul 21 23:09:05 UTC 2016


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.

Cheers
Michael


On Fri, Jul 22, 2016 at 8:13 AM, Bob Stewart <bob at evoria.net> 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 <jim77742 at gmail.com>
>  To: Discussion of precise time and frequency measurement <time-nuts at febo.com>
>  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 <brooke at pacific.net> 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:time-nuts-bounces at febo.com] On Behalf Of Tom Van
>>> Baak
>>> Sent: Thursday, July 21, 2016 1:28 PM
>>> To: Discussion of precise time and frequency measurement <
>>> time-nuts at febo.com>
>>> Cc: Leap Second Discussion List <leapsecs at leapsecond.com>
>>> 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 -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>> and follow the instructions there.
>>>
>>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.



More information about the Time-nuts_lists.febo.com mailing list