What's the story on day/year from refclocks?

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> >>> There's magic code in the NMEA driver
> >> Maybe we should have a flag..
> > I'm opposed to adding flags until an actual need is demonstrated.  If we're
> > going to add test and documentation complexity, it should be because we know
> > we have to do it. 
> 
> I agree with the philosophy, but I'll withhold final judgment until somebody 
> figures out what is actually going on.

...which is definitely on my list of things to untangle after 1.0.
For a very practical reason; if the code in NMEA that deduces a
4-digit year can be used by other drivers, more of them can drive ntpd
running with no network peers.

> Fixups based on the build date are (relatively) easy to understand and 
> explain.
> 
> Fixups based on file system dates work fine as long as everything is working 
> fine.  But what happens if, somehow, the file system date jumps to the 
> future?  Explaining that won't be fun.  What happens if the box sits on the 
> shelf for several years?

None of the wraparound kluges depend on filesystem dates.  The hacks for
disambiguating two-digit years work in one of two ways:

1. In the NMEA driver, calendrical black magic that's supposed to work
   until 2399.

2. Elsewhere, the year is deduced from the receipt time of the last
   incoming clock sample.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.