Hi Warner,
On 2016-07-20 11:34 AM, Warner Losh wrote:
On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris <bro...@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@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
