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. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
