[LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-06 06:30 PM, Tom Van Baak wrote:
>> I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is
>> signaled, but how its encoded is complicated, and when its updated is
>> unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can
>> anyone speak to that and this topic? What does GPS do? Is it clear? Or
>> does it actually suffer from this same ambiguity we are discussing?
> Remember, the alleged ambiguity is only about the what / when of time scale integer offsets. There's no ambiguity in TAI or UTC or GPS time stamps themselves. GPS receivers tend not to output anything like an offset, so they are immune from this discussion.
Sure, GPS navigation relies on GPS time, not UTC. That's the whole point 
of its primary timescale; ignoring UTC for that purpose. PTP does the 
same - UTC is treated as a second class citizen.
>
> Most commercial GPS timing receivers tend to output GPS time or UTC; there are internal configuration commands. Their UTC rolls over as one would expect and they output 23:59:60 appropriately.
That's where my question is. A GPS receiver would read the UTC metadata 
supplied in the GPS signal to generate UTC 23:59:60 from the primary GPS 
time, right?

We see from this discussion there are several ways folks use to 
calculate this conversion, but what method to use may depend on the 
organization of the metadata.

How is the UTC metadata handled in a GPS receiver? IS-GPS-200G, 
20.3.3.5.2.4 Coordinated Universal Time (UTC) explains a lot, but its 
pretty complicated how the various metadata components are encoded and 
updated. My question is, after decoding and adjusting the GPS data, when 
is the TAI-UTC portion of the metadata updated? At the beginning of, or 
the end of, the Leap Second?
> To get TAI one just adds 19 to GPS time. So no worries either way.
Right, but I am still a little worried.

If I were building a GPS-to-PTP receiver/generator, how would I read the 
GPS UTC metadata to populate the PTP UTC metadata? In particular, when 
should timePropertiesDS.currentUtcOffset be incremented? This has 
critical significance to the device receiving the PTP signal if accurate 
UTC is a requirement.

>
> Some cheaper GPS receivers output UTC date and time only, via easy-to-use NMEA sentences. In addition, by design, they avoid a 23:59:60 time stamp, which would upset upstream instruments. So during a leap second they either output 23:59:59 twice, or output 00:00:00 twice, or stutter and reset and stumble into the next day.
"Stutter and stumble" is not the sort of behavior we're seeking, I hope. :-)

This goes back round to the question of how UTC is mapped into 
86400-second-day systems, such as POSIX time. Does the Leap Second map 
to 23:59:59>23:59:59 (freeze), or 00:00:00>00:00:00 (rollover and reset)?

David Wells says NTP does the first, and POSIX time does the second:

The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html

And, back round to the first question, section 5. How NTP Implements 
Leap Seconds says quite clearly TAI-UTC increments *after* the Leap Second.

-Brooks

>
>> Also, NIST Special Publication 250-67 NIST Time and Frequency Radio
>> Stations:
>> WWV, WWVH, and WWVB
> Yes, there is a bit to indicate a pending leap second at the end of the current month. The sign of DUT1 is used to distinguish a positive from a negative leap. The data frames used by WWV and WWVB are 60 seconds long.
>
> For a positive leap second a blank second occurs between the last minute of 2016 and the first minute of 2017. The blank second is definitely not part of the 2017 minute. You could argue it's not really part of the 2016 minute either; it's just extra second. Again, there's no concept of transmitting a TAI offset, so no worries here either.
>
> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>