[time-nuts] 2015 Leap Second
Tom Van Baak
tvb at LeapSecond.com
Sat Jan 24 21:58:14 UTC 2015
More info from Charles (stuck in time-nuts @yahoo @aol prison):
/tvb
----- Original Message -----
From: Charles Zabilski
To: Tom Van Baak
Sent: Saturday, January 24, 2015 1:52 PM
Subject: Re: 2015 Leap Second
Tom:
Thanks for the update. I got around that problem in later versions of the GPS Control Program with alternate menu selections:
Set Leap Second as Indicated
and
Set Leap Second Only in Jun, Dec
If the GPS Receiver indicates the incorrect month (as the HP ones do), you select the Jun, Dec menu and it forces the programs display to hold off until June and reflects this fact in the display of the pending leap second. Last time I recalled that the GPS receiver performed the leap second in June 2012, notwithstanding the incorrect indicated date. The GPS Control Program also jams the program's display to force the correct counting sequence 58, 59, 60, 00, 01 etc. notwithstanding the incorrect sequence the receiver itself performs. However al lof these fixes are downstream of the receiver,
There have been postings about the Datum TS-2100 being a second slow once it detected a pending leap second in the GPS data. I was able to correct this issue by forcing a -1 leap second in the 2100 today with the Leap -1 01/24/2015 21:32:00 command. The 2100 is now displaying the correct time. I also followed it up with the correct leap second command Leap 1 07/01/2015 00:00:00 so that it will keep proper time following the actual leap second. I would appreciate it if you could post this info.
Thanks
Chuck Zabilski
On Saturday, January 24, 2015 2:35 PM, Tom Van Baak <tvb at LeapSecond.com> wrote:
Hi Chuck,
Thanks for the comprehensive list. Very nice work. This bug in many versions of the HP SmartClock-series has shown up before (but not always in the 90's, see below). What's going is yet another problem with how developers write code for leap seconds. It's really hard to get right.
There is a distinction between when leap seconds are *announced*, usually 2 to 6 months in advance (somewhat variable, almost random) and the month in which a leap second actually *occurs* (a very specific instant).
Unfortunately, the word "pending" is ambiguous since it does not distinguish between the casual advising that a leap second will occur many months in the future and the actual month in which the leap second occurs. This leads to both human and technical confusion.
In addition, there is confusion about when a leap second *can* occur. The UTC specification implies a leap second may occur at the end of any month, although it is most likely the 6th or 12th month, and if not that, the 3rd and 9th month. Some vendors have misinterpreted this to mean, for example, that if a leap second is announced in January it will therefore occur in March (rather than June). Oops.
These are difficult bugs to fix. For most of the 70's, 80's and 90's leap seconds were announced only a few months ahead of time. But in the past decade, IERS had been able to predict leap seconds almost 6 months in advance -- and this exposes bugs in software that used to work just fine.
/tvb
----- Original Message -----
From: Charles Zabilski
To: Tom Van Baak
Sent: Saturday, January 24, 2015 9:47 AM
Subject: 2015 Leap Second
Tom:
Unfortunately I no longer receiver emails from time nuts due to my @yahoo.com email address. In response to your desire to pull together a list of GPS receivers' handling of the upcoming leap second, please see the following:
Receiver 1st Reported date Reported Leap Sec Date
Z3801A 22 Jan 2015 31 Mar 2015
Z3811A 22 Jan 2015 31 Mar 2015
Z3816A 22 Jan 2015 31 Mar 2015
58503A 22 Jan 2015 31 Mar 2015
58503B 22 Jan 2015 31 Mar 2015
59551A 22 Jan 2015 31 Mar 2015
Z3805A No Leap Second Indication
Z3815A No Leap Second Indication
Please note that I usually only check for the leap second notifications in the mornings. In all probability the notifications occurred some hours earlier. Also, I am communicating with the GPS receivers through the external Com port using my GPS Control Program and not examining the internal GPS module data stream.
I hope this is of some assistance.
Chuck Zabilski
BD Systems, Inc.
Evergreen, CO
More information about the Time-nuts_lists.febo.com
mailing list