Verified - ntpd ignores the year part of refclock timestamps

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> >> We could test fixup software by setting the system clock
> >> ahead far enough to look like GPS had rolled over.
> 
> > What kind of fixup?  I looked long and hard at this problem in the context
> > of GPSD.  I never found one that wasn't as bad - or worse - than relying on
> > the sysrem clock date. 
> 
> I was thinking of testing the code to fixup a device that had rolled over and 
> was now off by 1024 weeks.
> 
> Pretend the date is 1024 weeks in the future.  Now a good GPS device looks 
> like it has rolled over and is giving bogus time.  Build ntpd with the pivot 
> date set to 10 years in the future and run it with the system clock set to 15 
> years in the future.  ntpd should fixup the GPS date and jump to 1024 weeks 
> in the future.

Nothing we do with the system clock in a test setup tells us how we
can compensate in production, because one of our premises is that at
startup we can't trust the system clock.  I was willing to do that in
GPSD only because at the time I thought we were mainly in the location
business rather than the time business; if we do it in ntpd, we sabotage
autonomous operation.

See http://blog.ntpsec.org/2017/08/30/achieving-autonomy.html if you have
not already.

We *can*, on the other hand, trust the observation that the pivot date is
greater than the time/date the GPS is returning.  If we see that, we know
the GPS has rolled over, but we can't tell how many times it has rolled
over.  (This will become a question after the second rollover in 2019).

We could try assuming it has only rolled over once, but one obvious way
for that to go wrong is if the ntpd pivot date is more than 1024 weeks in the
past.  *That* is going to become an issue for our earliest installations
right around the time of the 32-bit POSIX time wraparound.

It's a hall of mirrors.  Every time you think you've found a way out,
you're staring at another one of your own assumptions.
-- 
		<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.