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.

We typically reserve the word leap second "pending" for the month in which the 
leap second will actually occur. 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.

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

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

Reply via email to