Hal Murray hmurray at megapathdsl.net
Thu Apr 20 21:57:53 UTC 2017

We need a web page that summarizes this area - not the internal details, but 
the general problem and how it impacts users.

NTP overflows in 2036
32 bit signed time_t overflows in 2038
GPS overflows every 1024 weeks (~20 years starting from 1980)
  First rollover was 22 August 1999
  They added 3 bits in ???
  Some older devices used pivot logic to extend their lifetime past 2000

A description of pivoting and how it works.

Maybe mention the distro reproducible problem and __DATE__

Good URLs for more info


I see 4 ways to for ntpd to handle pivoting.

1) The current code does the pivoting at step_systime

2) We could do the pivoting "as soon as possible", when the received packet 
arrives.  The NTP calculations use 4 time stamps: 2 local, 2 remote.  The 
local time stamps need to save the timespec used to produce them.

3) We could assume that the system time is "close enough".  That turns into 
pivoting around "now".  That assumes that the system has a sane RTC or 
software that does something like get a sane time from the file system.  
"close enough" doesn't have to be very close.  Within 50 years is good enough.

4) We could add a few lines of code to the initialization of ntpd that jumps 
bogus time to some compiled in value.  The old way to get that value was 
__DATE_ but the last git commit date or something similar from the distro 
environment avoids the reproducible problem.  This is pivoting around the 
build date.


We need to verify that ntpdig does something sane.

As long as we are cleaning up this area...

32 bits of seconds spans 136 years.  ntpd panics if it is about to step the 
clock more than 900 seconds.  There is a startup switch to bypass that and 
allow one long jump.

We could supplement that sanity check with a pivot check.  If we have a build 
date, we know the time should be after that build date and less than the life 
of the program past that.

What's a reasonable life of a program like ntpd?  20 years seems like the 
right ballpark.  After that, we have to check the GPS drivers.  The magnovox 
driver just checks for before.  I haven't checked the NMEA driver.  50 would 
be more conservative for IoT type devices.  (Many GPS devices lasted long 
enough to hit the week roll over bug.)  Configure options, both build and 
run-time, could help but they would probably be ignored by the few people who 
should use them.

These are my opinions.  I hate spam.

More information about the devel mailing list