Hal Murray <hmur...@megapathdsl.net>:
> The problem I'm interested in is not Y2K, it's GPS rollover. 1024 weeks is
> not an integral number of years. The day and month are garbage too.
Right, not the same problem.
> I agree this is a mess. I think we need a flag to go with with the year.
> Then we can update the drivers to provide the year (and set the flag) as we
> get to them.
It's easier than that. I already have a patch that passes the year into
clocktime, and you can always tell when you had a 4-digit year because the
value passed in will be > 99. All that's needed is one line to set the
yearstart variable from a 4-digit year number.
Dead easy to test, too. The NMEA driver uses a weird calendrical
trick I don't quite understand (that it says will only work until
2399) to deduce the current century and *always* passes 4 digits; all
that needs to be checked is if the new logic computes a sane yearstart
value - the existing code will do the rest.
While it's kind of weird that nobody fixed this before, it's a nice
improvement to add to our new-feature list. Makes it actually
possible to run autonomously starting from a zeroed system clock with
one or more local refclocks and no network peers.
> How many of the GPSD test sets for NMEA have 2 digit years?
Most of them. You don't get a 4-digit year unless the device emits
GPZDA, which is unusual - most consumer-grade hardware does not. The
mt3339 used in the Adafruit HAT does.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
