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

[Greg Troxel]

"Eric S. Raymond" <address@hidden> writes:

> In theory we might be able to copy Perly's code so it corrects dates
> for rollover internally to GPSD.  I'll stare at it and see if I think that's
> feasible.

(not sure this is going to be helpful, but)

as I understand the situation, the GPSr is calculating a fix in GPS time
(in weeks and seconds), and has a truncated week value.  It is supposed
to disambiguate the truncated week value to the right one, and then
convert to UTC and then to whatever external representation (yymmdd
etc.)  it is using.   So I think the wNk fix would be simply going to
timeval from the external representation and then

  while ( t < PIVOT_TIME)
    t += 1024 * 7 * 86400;

And the trick is finding pivot time, so that we have the highest
probability of being helpful and vanishing odds of making things worse,
over the ensemble of people who are behaving at least sort of sanely.

To me, that means it's ok to assume gpsd is updated at least every 5
years or so.  I realize there are people that want to burn in embedded
code and let things run longer, but I think it's ok to leave the harder
problems for them to solve and contribute.

So I'd pick a pivot time that is well in the past when it is committed,
and update it not all that frequently.   I'd suggest avoiding near the
actual w2k time, just because I can't quickly convince myself it's ok to
be close.   So I would pick 2018-01-01 or something like that, skip
2019-01-01 as close, and then move to 2020-01-01 when we get to
2020-07-01.

To ensure the update to the hard-coded pivot time happens, I suggest
adding a regression test that throws an error when now-pivot > 3 years.

Anything that tries to use a current notion of time feels way too
dangerous; that should be within a receiver ratcheting forward, and then
needs a reset mechanism.  With gpsd updated every 10 years on a device,
there's no need.