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

[Tom Van Baak]

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" <holrum at hotmail.com>
To: <time-nuts at 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.