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

[Eric S. Raymond]

Michael J. Tubby B.Sc. MIET <address@hidden>:
> 
> 
> On 22/06/2019 08:30, Hal Murray wrote:
> > >     2. The system time being correct *before* gpsd invocation would give 
> > > it
> > >     a clue
> > There is no pivot logic on the ntpd side when looking at SHM.
> > 
> > I thought there was pivot logic for the NMEA driver, but I can't find it.  
> > It
> > may be in the parse/generic driver.
> 
> There is pivot logic in the TSIP Parse Driver - I put it there about 6
> months before the first roll-over in August 1999 - it goes:
> 
>     if (week_no <= 990)
>         week_no += 1024;
> 
> I guess this approach would work for some (old) GPS receivers:
> 
>     if (week_no < 1024)
>         week_no += 2048;
> 
> but the problem is the *very* old ones are easy to fix but the 10-12 year
> old ones less so because there are other arbitary pivot points in different
> firmware by different manufacturers.
> 
> 
> We are currently in week number 2058 so I guess:
> 
>     if (week_no < 1024) {
>         week_no += 2048;
>     } else if (week_no < 2058) {
>         week_no += 1024;
>     }
> 
> might kick the can down the street for a while longer ...
> 
> Mike

These per-driver hacks are dangrous kludges that store up trouble for
the future.  They should all be ripped out.

There's a more robust approach to the problem in refclock_nmea.c.  Take
a look at gpsfix_century() and unfold_century().

The right thing to do would be to take all two-digit dates and GPS
dates through the same unfolding logic. That is, the TSIP Parse Driver
(and other GPS types) should share the same date disambiguation logic
as the NMEA driver.

After we ship the point release I'll do a bit of refactoring to
facilitate this - move that code out of refclock_nmea.c and put it in
libntp where refclocks can call it.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>