Bogus results from NMEA/WNRO tangle

[Hal Murray]

Thanks.

Gary said:
>> We need 2 pivot dates, one for the 2 digit year fixup, another for
>> the WNRO fixup.

> More than 2, as WKRO happens every 1024 weeks.

I don't understand how you are counting.  I see one pivot date for WNRO.  The 
fixup may have to take multiple steps but there is only one date to compare 
against.

Note that the dates we see may not pivot at a GPS pivot date.  The firmware in 
the GPS unit may have its own fixup code pivoting around its own release date.


>> We need to add a pivot date to the release recipe -- something to
>> replace the build-date that we removed to make builds predictable.

> Maybe use the latest release data?  Then we still get predictable builds.

I'm setting things up so there is a header file that gets updated with a 
manual edit.  It needs to be done a bit before the actual release rather than 
when editing VERSION.  The catch is that the testing stuff has some tests that 
may need fixing if the pivot date changes.  I think the release announcement 
is a good time.  Anytime between releases is also OK.


>> I'm a bit surprised that Eric's early code removal effords didn't
>> spot the calendar code.

> Few GPS had rolled over then, so not a well understood issue. 

No, that's not the problem.  There is just a lot of code doing calendar 
conversions when Unix/POSIX already does almost what we need.  It's the sort 
of thing that Eric likes to clean up.

Things like WNRO fixup can be done by adding 1024*7*86400.  There is no need 
for any calendar conversions.

The refclocks need to convert things like YYYY-MM-DD to seconds.  POSIX should 
provide that, but doesn't.  See next chunk.

>> One problem with my current code is that Posix doesn't provide a UTC
>> version of mktime.

Garbage typo of mine.  That should have been:

One problem with my current code is that POSIX doesn't provide a reverse of 
gmtime.  localtime is the reverse of mktime but they both use the local time 
zone.  gmtime uses UTC, but there is no reverse.

timegm is in Linux and BSDs.  If we want to run on a system without it, we can 
grab a copy form the web.


[GPS NMEA units without a sentence with year.]
> Yes.  A lot of receivers on output GPGGA, or GPGLL, and nothing else.

OK.  Thanks.  I won't nuke that code.


>> It needs to handle the case where the GPS time and system time
>> cross day boundaries.  That is unlikely to get tested.

> Just once a day...

Maybe.  But if the system time is close to correct and the GPS sentence comes 
in at a significant offset from the second tick, then they will both be in the 
same second and hence same day.

I think I can hack a test by bumping the local time by a constant (say an 
hour) before the conversion then unbumping it after the conversion.

-- 
These are my opinions.  I hate spam.