Should two-digit years be fatal to a refclock?

[Mark Atwood, Project Manager]

I'm going to decide to not to decide right now.  We leave those refclocks
in for now.  This conversation is illuminating.

On Wed, Feb 6, 2019 at 9:32 AM Eric S. Raymond via devel <devel at ntpsec.org>
wrote:

> Richard Laager via devel <devel at ntpsec.org>:
> > I have (and was/am using) a clock using the Spectracom driver, with the
> > two-digit year. It recently suffered from GPS rollover, so I disabled
> > the GPS source in ntpd. I'm using the PPS source with network sources
> > (which I was using anyway) to number the seconds. This works well. I
> > didn't really care about the GPS source anyway. So if you were to remove
> > the driver, I wouldn't care.
> >
> > That said, if we wanted to do a better job in that driver, the following
> > pseudocode seems like it would produce the right results:
> >
> > We get a two-digit year and a day-of-year number. There is no
> > month/date, which I think is used in the NMEA driver to detect and
> > correct GPS rollover.
> >
> > ----
> > // Calculate the year assuming the clock works (no GPS rollover).
> > full_year = year + 2000;
> > while (1) {
> >     date = get_some_date_thing(full_year, day_of_year);
> >     if (date > BUILD_EPOCH)
> >         break;
> >     full_year += 100;
> > }
> >
> > // Calculate the year assuming GPS rollover
> > if (year < 90) { // or some similar fixed value
> >     full_year = year + 2000;
> > } else {
> >     full_year = year + 1900;
> > }
> > date2 = get_some_date_thing(full_year, day_of_year);
> > while(1)
> > {
> >     date2 = get_some_date_thing(full_year, day_of_year);
> >     if (date2 > BUILD_EPOCH)
> >         break;
> >     date2 = date2 + 1024 weeks;
> > }
> >
> > if (date2 < date)
> >     date = date2;
> >
> > // Use date
> > ----
> >
> > When my clock was working, it was outputting "18". Both approaches would
> > output the same thing, which is correct. This would work until 2090.
> >
> > Once my clock's GPS rolled over, it started saying 99. Today, it is
> > outputting "99 174". The first block would make that 2099 (as would the
> > current code). The second block would get the correct value. Note that
> > they will always be past the build epoch, so we just take the lower one
> > to find the one closer to the build epoch, which here is the right date.
>
> Please file this as an RFE, with some explanation of what
> get_some_date_thing()
> needs to be doing - I can't quite get it from this.
> --
>                 <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.
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-- 

Mark Atwood
http://about.me/markatwood
+1-206-604-2198
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190206/50bb3d32/attachment-0001.html>