Re: [gpsd-dev] gpsd rolls back to 1999

[Greg Troxel]

>> Can someone explain "magic calendar hack"?  Maybe that is addressing a
>> different receiver bug.
>
> Have a good hard look at ntpd/ntp_wrapdate.c. The functions unfold_century()
> and eval_gp_time() are clrarly doing morte elaborate versions of this sort
> of periodic extension.

I am assuming you are referring to

https://gitlab.com/NTPsec/ntpsec/blob/master/ntpd/ntp_wrapdate.c


I see - there are multiple things going on here, and it would be good
to try to keep them separated as much as we can:

  dealing with a time that is seconds since the GPS epoch, or
  equivalently week number and seconds of week.  This is the main thing,
  for devices that report in seconds.  I'll call this the W1K problem.

  dealing with devices that report two digit years, or Y2K.

  trying to use the leapsecond field to figure out the W1K epock, by
  having some table of known values for various years.

  Some computers have 32-bit time_t

  Some computers boot up with 0 in unix timeval, so we can't assume the
  system clock is even close.

and my approach is

  Pick a W1K pivot, 2018-07-01,  and advance by W1K units until >=.

  Use 70 or 80 as the pivot for Y2K for now (and deal with 2070 by
  2050).  I tend to 70, because while 80 is GPS epoch start, 70 is
  timeval, and it feels like asking for trouble to put 79 as 2079,
  especially since no reasonable system will see either for almost 60
  years.  If presented with a time only in NMEA and not seconds, apply
  this rule to the YY to get YYYY and then convert to seconds since GPS
  epoch and then apply the W1K fixup.

  Don't try to use leapseconds to guess epoch.  Receivers seem to boot
  up with leapseconds from their firmware and then get a new value.
  This just feels way too complicated, and the "add W1K if t < pivot,
  repeat" approach seems entirely adequate.

  Assume people upgrade to a 64-bit time_t and don't worry about that at
  all.

  Don't use the system clock at all in processing time data from a GPSr.

I can appreciate the nerd tendency to extrat the most information from
various broken processes, and backing out leapsecond data is cool, but I
don't see it as solving a problem that the YY->YYYY and W1K fixups
don't.   I get it that it might deal with 2150 now, but I see little
point in that.  The right fix is not to make ntp/gpsd smarter by then,
but to stop using two digit years.