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

[Brooks Harris]

On 2016-07-20 11:27 AM, Martin Burnicki wrote:
> Brooks Harris wrote:
>> On 2016-07-20 01:08 AM, Tom Van Baak wrote:
>>> 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."
>>
>> 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?
> Each bulletin C from IERS says:
>
> "Leap seconds can be introduced in UTC at the end of the months of
> December  or June, depending on the evolution of UT1-TAI. Bulletin C is
> mailed every six months, either to announce a time step in UTC or to
> confirm that there will be no time step at the next possible date."

Hi Martin,

Right, thanks.

We all understand Bulletin C is the single most official Leap Second 
announcement, but its not a specification. That paragraph contributes to 
the incorrect impression that "Leap seconds can be introduced in UTC at 
the end of the months of December or June" when in fact Rec 460 says 
"2.1    A positive or negative leap-second should be the last second of 
a UTC month, but first preference should be given to the end of December 
and June, and second preference to the end of March and September.". 
That means it can happen at the "end of any month", as Tom points out, 
and only that "preference" be given to December, June, March, and 
September.

Exactly what "preference" means in Rec 460 is a little vague, too, but 
we get the idea that IERS makes a judicious balance between the 
precision of UT1 v.s. UTC and convenience of some "end of month". It 
might not be directly relevant to UTC implementations but it would be 
comforting to know more clearly how IERS does that. It might be 
explained in their conventions, I'm not sure. The various guidance 
documents are helpful, but not definitive. One wishes there were a 
single document with common terminology that had undergone due-process 
to yield an official specification.

Bulletin C is but one of several "products" of the IERS. Bulletin C, 
curiously, does not specify an "expiration" except as implied by the 
statement "Bulletin C is mailed every six months, either to announce a 
time step in UTC or to confirm that there will be no time step at the 
next possible date." I'm not exactly sure what that means, because, 
presumably, Leap Seconds could occur more frequently.

Meantime, https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat 
says clearly, but in comments, "#  File expires on 28 June  2017". This 
seems to be a *promise* by IERS that they won't declare another Leap 
Second until then, but its not stated anywhere that I know of that that 
is officially true. We might surmise Bulletin C's "mailed every six 
months" statement corresponds to this expiration date and that's 
generally its meaning, but it all seems just too vague to me.

Then, of course, there's the obvious missing link - a common, 
standardized, method of automatic Leap Second metadata dissemination and 
retrieval. This topic has been discussed here many times, yet no 
official standardization process involving the BIPM, IERS, and ITU seems 
to be underway. That, it seems to me, would be an important step.

None of this is in any way a criticism of BIPM or IERS. They and all 
their contributing members do a utterly fantastic job of the "heavy 
lifting" of timekeeping. But if Leap Seconds are going to work better 
more clarity in all the documents is needed. I'm just trying to 
contribute to the conversation.

-B

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