Yo Hal! On Tue, 28 Dec 2021 13:35:33 -0800 Hal Murray <halmur...@sonic.net> wrote:
> > That is the important part. gpsd handles that just fine:
>
> Is there anything tricky about the fixup code?
Nope. gpsd/timebase.c, line 322.
Here is the meat:
/* sanity check unix time against leap second.
* Does not work well with regressions because the leap_sconds
* could be from the receiver, or from BUILD_LEAPSECONDS.
* Leap second 18 at 1 Jan 2017: 1483228800
* (long long) for 32-bit systems */
if (17 < session->context->leap_seconds &&
1483228800LL > t.tv_sec) {
long long old_tv_sec = t.tv_sec;
t.tv_sec += 619315200LL; // fast forward 1024 weeks
Basically, if the GPS reports more the 17 leap seconds, then the time
has to be aster 1 Jan 2017.
The regression tests are dealt with elsewhjere.
> I was expecting a few lines of code. The existing code is much much
> more complicated than that.
I assume you are talking about the NTPsec code. THat does look excessive.
> Is there any magic not-before date in the ntpsec environment?
gpsd has BUILD_LEAPSECONDS, and BUILD_CEDNTURY.
> I think we used to have the build date in the version string but that
> was removed to make builds reproducable. I thought we added
> something in a #define someplace with the idea that it would get
> updated with each release, but I can't find it.
Ditto for gpsd.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
g...@rellim.com Tel:+1 541 382 8588
Veritas liberabit vos. -- Quid est veritas?
"If you can't measure it, you can't improve it." - Lord Kelvin
pgpA3gsgPVUNr.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
