Leap second to be introduced at midnight UTC December 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.
On Tue, Jul 19, 2016 at 11:39:29PM +0000, Mark Sims wrote:
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.
I think some (modern!) Trimble gear may also has a problem. I have an ICM
SMT 360 board that's (slowly) flipping back and forth between showing a UTC
offset of 17 seconds and an offset of 18 seconds. This is their currently
shipping timekeeping chip, so it's surprising, but I don't know how else
to explain the behavior outside of a firmware bug.
(I've sent an email to Trimble support, but haven't heard anything back yet.)
-j
Hi Mark,
Three comments:
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.
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.
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@hotmail.com
To: time-nuts@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.
Yo Tom!
Here we go again. Leap seconds always cause stress...
On Tue, 19 Jul 2016 22:08:48 -0700
"Tom Van Baak" tvb@LeapSecond.com wrote:
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.
NTP Classic thinks otherwise:
http://bugs.ntp.org/show_bug.cgi?id=1090
gpsd follows the lead of NTP folks.
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.
Got a reference for that? I know many people that will insist otherwise.
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Yo Tom!
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.
Got a reference for that? I know many people that will insist
otherwise.
Never mind, I think I found a reference that is commonly quoted:
CCIR Recommendation 460-4 (1986).
http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.
But it is marked Superceded. I'm guessing that is replaced by 460-6?
http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en
It says the same thing in section 2.1
Nothing says it has to be those 4 months...
I have some code comments in gpsd to fix...
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Gary,
On 07/20/2016 07:36 AM, Gary E. Miller wrote:
Yo Tom!
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.
Got a reference for that? I know many people that will insist
otherwise.
Never mind, I think I found a reference that is commonly quoted:
CCIR Recommendation 460-4 (1986).
http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.
But it is marked Superceded. I'm guessing that is replaced by 460-6?
http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en
It says the same thing in section 2.1
Nothing says it has to be those 4 months...
No, but the wording do say that those four month is preferred. For those
that is curious:
http://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf
8<---
2 Leap-seconds
2.1 A positive or negative leap-second should be the last second of a
UTC month, but first preference should be given to the end of December
and June, and second preference to the end of March and September.
2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of
the first day of the following month. In the case of a negative
leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s
of the first day of the following month (see Annex 3).
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.
--->8
Thus, any month can be scheduled, but there is a preference to end of
half-year and then end of quarter. The main preference is used in
practice, which is in good accordance with the rules, the Z3801A
designers over-eagerly included also the remaining two end-of-quarter.
I have some code comments in gpsd to fix...
Yes, but it can take a long time before it would bite you.
Beware of GPS-receivers such as Z3801A which now give the time of leap
second 3 month to early, and beware that eventually end of March and end
of September might become legal points even for a Z3801A.
Now, what annoys me is that the IERS message says that the leap second
is scheduled for January:
8<---
Paris, 6 July 2016
Bulletin C 52
To authorities responsible for the measurement and distribution of
time
UTC TIME STEP
on the 1st of January 2017
A positive leap second will be introduced at the end of December 2016.
The sequence of dates of the UTC second markers will be:
2016 December 31, 23h 59m 59s
2016 December 31, 23h 59m 60s
2017 January 1, 0h 0m 0s
--->8
It is unfortunate that it says UTC TIME STEP on the 1st of January 2017,
as it is scheduled for 31 December 2016.
This is a new habbit of IERS, and it is unfortunate and not helpful.
Older Bullentin C used the more correct reference to end of June or end
of December.
Ah well.
Cheers,
Magnus
Hi Gary,
2.1 A positive or negative leap-second should be the last second of a UTC month,
but first preference should be given to the end of December and June,
and second preference to the end of March and September.
Sounds correct. The point is to never to hardcode a "preference". You code against a spec. And the spec is simple:
"A positive or negative leap-second should be the last second of a UTC month"
It would appear that assuming the preference was actually a rule is what causes the Z3801A f/w to mis-report the next leap second as September instead of December. Back in the late 90's, when the 58503/Z3801 code was written, this made sense. Leap second annoucenements were not made half a year in advance back then.
/tvb
----- Original Message -----
From: "Gary E. Miller" gem@rellim.com
To: "Tom Van Baak" tvb@LeapSecond.com
Cc: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Tuesday, July 19, 2016 10:36 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC December 31 this year
Yo Tom!
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.
Got a reference for that? I know many people that will insist
otherwise.
Never mind, I think I found a reference that is commonly quoted:
CCIR Recommendation 460-4 (1986).
http://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
2. Leap-seconds
2.1 A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end of
December and June, and second preference to the end of March and
September.
But it is marked Superceded. I'm guessing that is replaced by 460-6?
http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en
It says the same thing in section 2.1
Nothing says it has to be those 4 months...
I have some code comments in gpsd to fix...
RGDS
GARY
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com Tel:+1 541 382 8588
Magnus,
Magnus Danielson wrote:
Now, what annoys me is that the IERS message says that the leap second
is scheduled for January:
8<---
Paris, 6 July 2016
Bulletin C 52
To authorities responsible for the measurement and distribution of time
UTC TIME STEP
on the 1st of January 2017
A positive leap second will be introduced at the end of December 2016.
The sequence of dates of the UTC second markers will be:
2016 December 31, 23h 59m 59s
2016 December 31, 23h 59m 60s
2017 January 1, 0h 0m 0s
--->8
It is unfortunate that it says UTC TIME STEP on the 1st of January 2017,
as it is scheduled for 31 December 2016.
Hm, the leap second is inserted at the end of December 31 (which is also
said by the message text), but as a consequence the beginning of January
1 is delayed by 1 second, so IMO this statement might be correct, even
though it's not formulated very clearly.
This is a new habbit of IERS, and it is unfortunate and not helpful.
Older Bullentin C used the more correct reference to end of June or end
of December.
Hm, the oldest bulletin C I found on the IERS web site already has the
same statement:
https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.10
I find it amusing that until ~2011, if no leap second was scheduled, the
message text said:
"NO positive leap second will be introduced ..."
If you're nitpicking you could have expected that eventually a
negative leap second was to be scheduled. ;-)
Martin
On Jul 20, 2016, at 12:25 AM, Tom Van Baak tvb@LeapSecond.com wrote:
Hi Gary,
2.1 A positive or negative leap-second should be the last second of a UTC month,
but first preference should be given to the end of December and June,
and second preference to the end of March and September.
Sounds correct. The point is to never to hardcode a "preference". You code against a spec. And the spec is simple:
"A positive or negative leap-second should be the last second of a UTC month"
Even that’s weasel-worded. If they mean it, they should say it will or it must be the last second of a UTC month.
Words have meanings. :D
Jay Grizzard wrote:
On Tue, Jul 19, 2016 at 11:39:29PM +0000, Mark Sims wrote:
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.
I think some (modern!) Trimble gear may also has a problem. I have an ICM
SMT 360 board that's (slowly) flipping back and forth between showing a UTC
offset of 17 seconds and an offset of 18 seconds. This is their currently
shipping timekeeping chip, so it's surprising, but I don't know how else
to explain the behavior outside of a firmware bug.
The UTC/leapsecond data sent by the satellites contains the UTC offset
before and after the leap second event time. This has been 17/17 until
recently, and is 17/18 now.
The GPS satellites didn't start all at the same time to send the new
data set, so there was a period of time where some sats sent 17/17 while
some others already sent 17/18.
So when the GPS receiver always just showed information on the current
UTC data set then this is OK. However, the time it has output should
not have jumped back and forth by 1 second.
Martin