Century correction absent in some refclocks

[Eric S. Raymond]

Question directed particularly to Hal and Daniel:

I have been working on a document that Hal Murray requested, a
comprehensive discussion of rollover effects in Unix, NTP, and
GPSD calendars.  Writing this has required me to read the refclock
code looking for how it copes with these.

There is a mystery around processing of year input from refclocks.

Some report 4-digit years with a century part - gpsd_json, some modes
of jjy and generic, magnavox, hpgps, the European modes of the modem
driver, zyfer.

Some only report 2-digit years - arbiter, some modes of jjy and
generic, the ACTS mode of the modem driver, neoclock, oncore,
spectracom, trimble, and truetime

In nmea, I see explicit code to derive a 4-digit year from a 2-digit
year using some calendrical trickery I don't understand - but for this
purpose it doesn't matter that I don't understand it, only that
someone thought it was neceessary.

What I don't understand is why the refclocks returning only 2-digit years
ever worked at all.  Does the sample-processing code simply ignore the
century part of the year?  If so, why is nmea supplying that?

Puzzled in Malvern...
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"

"I hold that such a question can never arise except in a society of cannibals."
	-- Ayn Rand