Should two-digit years be fatal to a refclock?

[Achim Gratz]

Hal Murray via devel writes:
> You can check that by looking at your syslog and/or ntp log files.
>
> The details may depend on the OS/Distro.
>
> From a clean reboot on Fedora, Pi 3.
>  2 Feb 17:46:14 ntpd[489]: PROTO: 192.168.1.33 unlink local addr 192.168.1.71 
> -> <null>
>  2 Feb 17:46:14 ntpd[489]: PROTO: 0.0.0.0 001d 0d kern kernel time sync 
> disabled
> 11 Jan 03:41:06 ntpd[498]: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-se
> conds.list'): stat failed: No such file or directory
> 11 Jan 03:41:06 ntpd[498]: INIT: Using SO_TIMESTAMPNS
> ...
> 11 Jan 03:42:20 ntpd[498]: PROTO: 192.168.1.3 b01a 8a sys_peer
> 11 Jan 03:42:20 ntpd[498]: PROTO: 0.0.0.0 c01c 0c clock_step +1951552.134334 s
>  2 Feb 17:48:12 ntpd[498]: CLOCK: time stepped by 1951552.134334
>  2 Feb 17:48:12 ntpd[498]: CLOCK: time changed from 2019-01-11 to 2019-02-02
>  2 Feb 17:48:12 ntpd[498]: PROTO: 0.0.0.0 c015 05 clock_sync
>  2 Feb 17:48:17 ntpd[498]: PROTO: 0.0.0.0 c018 08 no_sys_peer
>
> Looks like it's off by almost a month.

Left with no help from BIOS or RTC the kernel boots using its own build
time, I think.  Various distros have (or used to have) some code to
check for the RTC or the BIOS getting completely off-track.  This
amounts to looking at the timestamps of certain files and making sure
the system time is not older than one hour before that time (the hour
trying to acount for a possible DST switch).  None of these methods are
reliable by themselves, but a combination of these likely is.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada