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."
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?
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?
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.
There's more info on all of this back in the time-nuts and LEAPSECS archives if
you want to dig deeper.
2)
Note this is not a problem for LF time services like WWVB which reserve two
bits; one that tells you if a leap second is pending (this month) and one that
tells you if it's an insert (positive) or delete (negative) leap second.
I think *omit* is a better term than "delete" for a negative Leap
Second. YYYY-MM-DDT23:59:59Z isn't "deleted", its omitted from the
YMDhms labeling sequence.
[By the way, and there's no changing this, of course, but "Leap Second"
is itself a misnomer; only positive Leap Seconds produce a "leap" in the
YMDhms count. In the video business, in SMPTE timecode, there is a
compensating counting scheme (a "count mode") named "Drop-frame" where
some hh:mm:ss:frame labels are "dropped", or omitted. This is analogous
to a negative Leap Second. So a negative Leap Second could be called a
"Drop Second". I'm not suggesting that, but only to illustrate the point
of using the word "omit".]
For WWVB it's either this month or it's not at all.
It's a minor problem for NTP because it AFAIK it can only tell you one day in
advance if a leap second is going to happen at midnight.
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.
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.
-Brooks
It's a mess for NMEA; there are no standard messages that give leap second
announcements. The time just jumps or stutters, whether you or your boating
equipment expects it or not.
It's not a problem for GPS because internally a leap second is not indicated by
flag bits at all. Instead they use two fields for the pre- and the post-
UTC-GPS offset, as well as the GPS week/day number when the change takes/took
effect. So there's the potential for years of advance notice of a leap second.
So GPS is robust, WWVB is fine, avoid NMEA, and NTP is kind of fragile with
respect to leap second announcements. I assume Galileo does it right. GLONASS,
on the other hand, is known to have problems every time there's a leap second.
Just to be clear, this Z3801 anomaly is not a GPS problem. IIRC, it's not even
an Oncore VP GPS board problem either; instead the hp CPU firmware is overly
enthusiastic about how to transform a GPS leap second *announcement* into a
Z3801A leap second *pending*. But it all works out fine in the end; this has
happened on other recent leap second announcements, so not to worry.
3)
Some things to know, as a writer of software that involves users, GPS
receivers, and leap seconds...
If you're writing embedded software try to never hardcode any leap second
tables.
In general there's a common belief that a leap second can only occur at the end
of June or December. This is false. Don't ever hardcode this assumption.
There's also a less common belief that a leap second may occur at the end of
March, June, September, or December. This is also false. Don't hardcode this
either.
IERS is free to schedule a leap second at the end of any month. And it may be
an insert or a delete. Assume nothing more or less in your code. Code and test
and document for positive and negative leap seconds equally.
I say this because with the gradual warming / melting of the planet since the last major ice age we
may soon enter a decade where the earth returns to a "normal" 86400.000 seconds per day
or even a bit less. In that case we'll switch from positive leap seconds for a while, to no leap
seconds for a while, to negative leap seconds for a while. We got very close to this during the
years 2000 - 2007, when we entered the "no leap seconds for a while" stage.
I don't normally cross-post, but I'll cc the leap second list for comments or
corrections.
/tvb
----- Original Message -----
From: "Mark Sims" <hol...@hotmail.com>
To: <time-n...@febo.com>
Sent: Tuesday, July 19, 2016 4:39 PM
Subject: [time-nuts] Leap second to be introduced at midnight UTCDecember 31
this year
The GPS satellites are now reporting the pending leapsecond...
The Z3801A has it messed up... it says the leap will occur on 30 Sep 2016 (73
days). The Z3801A has two different messages that report the leap day... both
are wrong.
_______________________________________________
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
