Should two-digit years be fatal to a refclock?

[Achim Gratz]

Eric S. Raymond via devel writes:
> The failure cases are really hard to think about. There are all kinds
> of potential interactions among century error due to two-digit years,
> 32-bit wraparound in peer timestamps, unknown pivot dates on peers,
> GPS-era rollovers, unknown pivot dates in GPS firmware, and failures
> near RTCs.

You can have all these errors with four digit years.  Case in point: the
NavSpark modules I'm using have not backup battery, so they'll send out
GPZDA with a time back in 2006 after a cold boot.  Sure you can figure
out they've got no fix, but if all you look at is GPZDA then ntpsec will
pivot into February 2026 and happily set the system time (I'll have to
write an udev rule to reboot the GPS with the last known time and
position to mimic what the battery backup would do, but didn't yet).

> I meant to mention that one reason I'm a bit more worried about this
> is that the rise of hobby SBCs has made RTCless sysyems actually more
> common than they were a decade ago.

A system with an RTC that has a rollover problem or an empty battery is
just as common and produces the same sort of faults.  The lesson is to
not believe a single source of time, ever.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada