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

Jay Grizzard elfchief-timenuts at lupine.org
Wed Jul 20 20:45:30 UTC 2016


On Wed, Jul 20, 2016 at 09:37:02PM +0200, Martin Burnicki wrote:
> 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.

I don't actually know what the time it's outputting is (this particular
chip I'm grabbing stats from, but not time), but I'm pretty certain that
nothing should be returning '18' yet. In specific, from the docs for the
'UTC Offset' field in the Trimble docs for the TSIP primary timing packet
(0x8F-AB):

    This field represents the *current* integer leap second offset between
    GPS and UTC

(emphasis mine)

However, even if it was outputting the correct thing in the timing packets, 
that only applies if the GPS is set to report UTC time rather than GPS time
(which is selectable on Trimble chips).  You should be able to get GPS 
time from the output and add the UTC offset to get UTC time, but that won't
work with the data this chip is currently outputting.

Even if reporting 18 is correct, though, Trimble still has a problem,
because my Thunderbolt is still reporting 17, and I'm pretty sure they're
not both right (same company, same protocol, different values). Either that,
or Trimble provides a "UTC Offset" field with every timing packet that they
don't actually intend for anyone to use for anything, but that would just
be weird.

-j



More information about the Time-nuts_lists.febo.com mailing list