Re: [gpsd-dev] Leap Second - end of December

[Fred Wright]

I sent this privately by mistake:

On Sun, 10 Jul 2016, Fred Wright wrote:
> On Sun, 10 Jul 2016, Greg Troxel wrote:
>
> > thanks.  I guess I am misremembering.   I dimly recall some notion that
> > while leap seconds are only june/dec, some of the timecode specs allowed
> > them monthly and thus had to wait for the month.   That might be WWVB.
>
> What's actually supplied in the NAV message is the before and after
> offsets, and the week and day numbers of the change, with the only
> implicit assumption being that it occurs immediately prior to 00:00:00
> UTC.  Thus, it can be updated at pretty much any time, and the more
> warning the better, since it can take up to 12.5 minutes to get the latest
> value after signal acquisition.
>
> Some receivers might screw up if it's updated just before a week rollover.
> If there's a leap second in Jun-2019 we'll get to find out. :-)
>
> Theoretically, it could always broadcast the latest change, even when it's
> in the past.  In practice, they seem to switch to a "no change" version
> some time after it occurs.  That may partly be due to the fact that the
> "old" value is documented as the "current" value, for no terribly good
> reason.

Meahwhile, some time in the last 9 days, the NAV data started advertising
the new leap second.  From SxBlueIII binary data collected in the past
hour:

$Bin94(96): Ionospheric and UTC conversion parameters
  AFCRL Ionosphere alpha params: a0 = 7.450581e-09, a1 = 1.490116e-08, a2 = 
-5.960464e-08, a3 = -1.192093e-07
  AFCRL Ionosphere beta params: b0 = 9.216000e+04, b1 = 1.310720e+05, b2 = 
-6.553600e+04, b3 = -5.242880e+05
  UTC conversion params: A0 = 2.793968e-09, A1 = 7.105427e-15 at week/sec 
1906/589824 (2016-07-23 19:50:07 UTC)
  Leap seconds: current = 17, future = 18 effective after week/day 1929/7 (at 
2016-12-31 23:59:60 UTC)

Fred Wright