> (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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel