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

[Warner Losh]

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.

> 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.

I've not come across documentation of this practice, however. At least nothing
more than a similar statement to mine based on observed behavior.

>> 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.

>> 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.

> 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.

> 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.

Warner