[time-nuts] June 30 2015 leap second

[Martin Burnicki]

Tom Van Baak wrote:
>>> I haven't looked at the raw data, but using the windows apps:
>>> a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not.
>>> lady heather is not
>>
>> Interesting.  I don't see any leap-pending from a Z3801A.  (or a KS-24361)
>
> Hi Hal,
>
> It's not that simple. There are many different levels of leap second notification.
>
> 1) IERS updates their ftp site (for bots) and sends email (for humans) indicating when the next leap second will occur. Days or weeks (and sometimes months) later,
>
> 2) GPS ground control uploads almanac information to the satellites with updated UTC parameters. Four values in page 18 of subframe 4 give the current UTC leap second delta and also an optional future UTC delta, with a GPS week (LS_f) and day number (DN) when that future delta will be current. By definition the leap second will occur at the end of a UTC (not GPS) day.
>
> In this way GPS can provide up to 256 weeks (~4.9 years) of advanced
> leap second information and support positive or negative leap
> seconds.

Yes, and since the GPS UTC parameters just provide the difference to GPS 
time (in seconds) before and after the leap event time, they could even 
announce a leap event where more than 1 second is inserted or deleted at 
once. ;-)

I'm not aware of any other timing system that could handle this, though.

> Note there is no "leap second warning" *bit* in the GPS
> spec, per se.
>
> 3) Starting up to 12.5 minutes later, GPS receivers will see page 18 of subframe 4 from some or all SV and thus know not only the current UTC offset, bit when/if a different UTC offset will be valid in the distant future. Prior to this (e.g., cold start) there is no certainty of either the UTC offset or leap second state.
>
> 4a) Since UTC and leap seconds are not needed for navigation, some GPS receivers do not bother to tell the user about leap seconds at all.
>
> 4b) Some GPS receivers only give the user a leap second warning and so they must wait until the month in which the leap second is to be applied before they issue the warning. That means they may sit on the internal leap second information for many months.
>
> 4c) Other GPS receivers give the future date of the next leap second (if any). This is not a warning bit, but just the date/time of the next leap second.
>
> 4d) Especially dangerous are any GPS receivers that report only a leap second warning bit, but don't tell you which month it will occur.
>
> 5) Host software (e.g., GPSDO firmware, operating system, drivers, or apps) take this information and must only operate on it at the end of the appropriate UTC month. Hardcoded rules for June and December are frowned upon.
>
> It would be nice if we pooled together our resources and made a list of which GPS/GNSS receivers are 4a, 4b, 4c, or 4d.

It also depends on *how* the leap second warning is made available. If 
an application can read the GPS UTC parameter set then it can compute it 
as soon as the sats start to broadcast it.

There are formats of time string output by GPS receivers which only 
include the leap second warning 1 hour or 1 day before the event.

NMEA sentences don't include it at all, AFAIK. Binary messages may, 
depending on the manufacturer.

IRIG time code signals also don't provide a leap second *warning* flag, 
except the IEEE codes 1344 and C37.118, which only output this 10 
seconds or 1 minute (don't remember exactly without looking) before the 
event.

Martin