What's the story on day/year from refclocks?
Eric S. Raymond
esr at thyrsus.com
Sun Oct 1 20:37:09 UTC 2017
Hal Murray <hmurray at megapathdsl.net>:
>
> devel at ntpsec.org said:
> > There's magic code in the NMEA driver that computes the year from other dare
> > components based on some calendrical trick I don't understand. A comment
> > notes that it will fail in 2399.
>
> > Under consideration for 1.0, once I *do* undertstand it: making all refclock
> > drivers use this.
>
> That sounds like the sort of magic that could do the wrong thing without
> warning. Maybe we should have a flag to enable it and/or why would we want
> to add that to other drivers?
We might want to make available it to other drivers because they too
return only 2-digit dates. This is true of the Symmetricom type 2,
for example.
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.
> NMEA may be special since some of the date formats only have 2 digits of
> year.
As noted, that's not just an NMEA problem.
> I think the standard century rollover fixup based on the build date
> would be better than something that is hard to explain.
Better still, we could write a common century-rollover check that does both
things and complains if they don't match.
> Another possibility would be to have a per-driver GPS flag and apply the
> normal GPS rollover fixup based on the build date. That is at least
> reasonable to describe. But it only works for 20 years.
This area is worth a serious look once we ship 1.0.
--
<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.
More information about the devel
mailing list