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

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> 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.

You sound like you're developing a plan.  I'm happy for you to chew on
this problem, it frees me for some other things we need to do.

I can confirm one of your conjectures:

http://esr.ibiblio.org/?p=2869

http://esr.ibiblio.org/?p=2882
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>