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

[Brooks Harris]

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" <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.
>
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>