Bogus results from NMEA/WNRO tangle

[Hal Murray]

I think I've figured out what was going on.  There are 2 stages of fixup.  One 
is for the 2 digit year.  The other is for the WNRO.  The trick is that the 
year fixup has to let through known-bad years so the WNRO has the correct data 
to work with.

If the GPS unit puts out xx20 for the year, and the pivot date is 2021, that 
shouldn't be bumped up to 2120.

We need 2 pivot dates, one for the 2 digit year fixup, another for the WNRO 
fixup.

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

------------

I think I have refclcok_nema working without using any of the calendar stuff.  
It needs more testing.

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

One problem with my current code is that Posix doesn't provide a UTC version 
of mktime.  Linux and BSDs have timegm.  I propose we treat this the same way 
we handle the BSD string routines -- provide an implementation if the 
environment doesn't.

------------

There is code to use the current date for the NMEA sentences that provide time without any date.  That's GPGGA and GPGLL.  Is there a good reason to support that?  Is there any GPS unit that doesn't support a sentence with the date or any reason not to use it?

It's not a big deal, just some minor clutter with a few lines of slightly trickly code.  It needs to handle the case where the GPS time and system time cross day boundaries.  That is unlikely to get tested.



-- 
These are my opinions.  I hate spam.