[LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Brooks Harris]

Hi Warner,

On 2016-07-20 11:34 AM, Warner Losh wrote:
> On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris <brooks at edlmax.com> wrote:
>> Hi Tom,
>>
>> A couple questions and thoughts concerning standards and nomenclature -
>>
>> On 2016-07-20 01:08 AM, Tom Van Baak wrote:
>>> Hi Mark,
>>>
>>> Three comments:
>>>
>>> 1)
>>> I recall this is a known problem in the Z3801A status reporting, and
>>> possibly other GPS receivers of that era as well. It stems indirectly from a
>>> change years ago in how far in advance IERS and DoD were able to update the
>>> leap second info into the GPS constellation. Nowadays it's common to get 6
>>> months notice; it wasn't always that much.
>> TF.460-6 says:
>> "2.3    The IERS should decide upon and announce the introduction of a
>> leap-second, such an announcement to be made at least eight weeks in
>> advance."
> I seem to recall finding a really old version of TF.460 that didn't have the
> minimum time.
Could be. I've not researched when "at least eight weeks" came into it. 
But maybe no matter - what we need is clear specifications about what 
will happen when and exactly what it means....
>
>> Is there a statement in some document from BIPM or IERS that states their
>> current announcement policy? How, when, and why is it different from 460? I
>> mean, more lead time is a good thing, but what, exactly, is an implementer
>> to expect and what standard would would they look to learn and confirm that?
> 6 months (about 25 weeks) is at least 8 weeks, so it is in conformance with
> TF 460-6. However, that's a good question. Judging on what has happened with
> these announcements, one can count on no more than 6 months of lead time,
> though IERS is at liberty to make an announcement more than 6 months in
> advance.
Right. The lead time for making the announcement is not the same as an 
"expiration" or "promise". And the lack of specificity about what they 
may or may not do does not help consistency of implementations.
>
> I've not come across documentation of this practice, however. At least nothing
> more than a similar statement to mine based on observed behavior.
Thanks for the confirmation I haven't missed something by somebody 
somewhere.

>
>>> We typically reserve the word leap second "pending" for the month in which
>>> the leap second will actually occur.
>>
>> Is there a statement in some document that states this use of the word
>> "pending"? In my research, centered on published standards and conventions,
>> I've not encountered the word "pending" used this way, exactly. Where does
>> it come from and why?
> The "pending" bit comes from a long line of time gear that has a pending
> leap second light or other indication that a leap second is coming. It's the
> preferred jargon of the trade as well. I've seen it used in a variety
> of contexts,
> ranging from the IRIG context where, through an extension, you have about
> an hour's notice of the leap second (so the pending bit is set) to GPS receivers
> that indicate there's a pending leap second as soon as it gets pushed out to the
> almanac (since it's not a bit that's set, but states when the leap will happen).
>
> But mostly, I've seen many filters that limit the propagation of the leap second
> information to be a much shorter time. The only "safe" time to convent the one
> bit of information that 'we are having a leap second' is in the calendar month
> prior to the leap second. Leap seconds happen only at the end of any month,
> so that's the only way you can be sure. Common practice since 1972 has been
> to only schedule them in the primary slots of June and December.
OK, I see. "preferred jargon", but no official or due-process 
definition. So this leaves no *clear* distinction between "pending" and 
"announce".


>
>>> So just because we now know a leap second will occur in December we don't
>>> say, here in July, that a leap second is pending. Instead we say a leap
>>> second has been scheduled, or has been announced, or something like that.
>> "something like that" isn't very precise. Seems to me there should be a
>> statement in some official document that clarifies what words are to be used
>> and what they mean.
> I'd love to see that. However, much of the time-keeping practice isn't written
> down in official documents. It's enough of a niche thing that people in the
> profession are just expected to know the terms and conventions. They act
> as a shibboleth to other practitioners.
Yes, it sure is.
>
>> Many statements on this list and elsewhere casually say "at midnight". This
>> is very misleading to naive readers. I've been in discussions concerning
>> timekeeping protocols where there was a misunderstanding that "at midnight"
>> meant the first second of the day and the protocol would have introduced the
>> Leap Second incorrectly. It eventually got sorted out, but was an expensive
>> detour.
> Ah, many, many systems.... I fixed FreeBSD to repeat the last second of the
> prior day (as the least aweful of the choices) rather than to repeat
> the first second
> of the following day.
I'm not surprised to hear its happened elsewhere. It's a pretty big 
mistake if its allowed to happen, and that's where better documentation 
is needed to help head off errors like that.
>
>> With Leap Seconds now with us for at least a decade one would hope the BIPM,
>> IERS, and ITU might find a way to consolidate the UTC specifications with a
>> common and well defined nomenclature.
> Given we've been doing this for over 4 decades now, I'm surprised that such
> an animal doesn't exist out side of 'handbooks' that various timekeeping labs
> have put together to summarize.

That's where I think we all should somehow find a way to initiate such a 
document and process..

-Brooks

>
> Warner
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>