> 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. 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. To get TAI one just adds 19 to GPS time. So no worries either way. 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. > 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@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
