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

Scott Stobbe scott.j.stobbe at gmail.com
Fri Jul 22 15:58:08 UTC 2016


Hi Tom,

Thanks for your insights on days past, and great website. I haven't
convinced myself that you can always guarantee | DUT1 | <= 1 if you force a
leap second at the end of each month. Certainly would aid in combating
sketchy code. I tried it on a very rudimentary model to visualize it.

On Thu, Jul 21, 2016 at 6:58 PM, Tom Van Baak <tvb at leapsecond.com> wrote:

> > If UTC time was adjusted every month would stick with one full second? Or
> > some smaller quantity?
>
> Hi Scott,
>
> The LSEM month suggestion retains the UTC policy of leaps being exactly +1
> or -1 second, never larger, never smaller.
>
> There's a world of hurt if anyone even dreamed of shifting UTC by a
> fraction of a second. In fact, one of the main reasons UTC was created in
> the 70's was to put an end to the dreaded fractional jumps in atomic
> timekeeping during that era. Fractional steps atomic frequency and
> fractional steps in atomic time were both tried during 60's. For example:
>
> http://www.leapsecond.com/history/wwvb1966.htm
>
> Eliminating frequency jumps completely (by defining the UTC second to be
> 9,192,631,770 Hz cesium), and
> changing any steps to be full +1 or -1 second integers (and not fractions)
> was why UTC was created.
>
> /tvb
>
> ----- Original Message -----
> From: "Scott Stobbe" <scott.j.stobbe at gmail.com>
> To: "Discussion of precise time and frequency measurement" <
> time-nuts at febo.com>
> Sent: Thursday, July 21, 2016 3:06 PM
> Subject: Re: [time-nuts] LSEM (Leap Second Every Month)
>
>
> > If UTC time was adjusted every month would stick with one full second? Or
> > some smaller quantity?
> >
> > On Thursday, 21 July 2016, 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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: forced_leapsecond.png
Type: image/png
Size: 9616 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20160722/816c3605/attachment.png>


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