Should two-digit years be fatal to a refclock?

[Richard Laager]

On 2/4/19 3:58 PM, Hal Murray via devel wrote:
> What's wrong with just adding 2000 to 2 digit years?  We are in the 2000s now 
> so we don't have to consider the 1900 case any more.  I'd be happy to 
> reconsider dropping support for 2-digit drivers in another 30 years.
> 
> There is another roll-over consideration we should add to the list.  That's 
> the GPS 1024 week tangle.

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.

-- 
Richard