Should two-digit years be fatal to a refclock?

[Hal Murray]

> (I thought the RasPi stored a timestamp on a clean shutdown, then reads it
> back at boot time, so time is usually not actually zeroed. But I don't know
> that, and no such fallback is mentioned aty that link.) 

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.


> If the zero date was in the last century and your local refclock only ships a
> two-digit date, you have a problem. NTP will cheerfully "correct" the time
> into the last century.  This is a real problem case with RasPis or
> BeagleBones using a vanilla NMEA GPS.  So much for standalone operation,
> which we now advertise as an NTPsec feature. 

Didn't we discuss this a year or 3 ago?  I thought the solution is to pivot 
around the build date of ntpd.  There is a ntpcal_get_build_date() in 
libntp/ntp_calendar.c

It's called by refclock_trimble, refclock_nmea, and libntp/systime.





-- 
These are my opinions.  I hate spam.