Verified - ntpd ignores the year part of refclock timestamps

[Eric S. Raymond]

Hal Murray <hmurray at 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.