[LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
brooks at edlmax.com
Wed Jul 20 13:19:50 EDT 2016
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
>> 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."
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
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.
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.
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS