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