Time to slow down and be more careful

[Hal Murray]

esr at thyrsus.com said:
> This morning, while investigating a recent code change that smelled bad to
> me, I discovered that an error cascade of small, wrong changes starting some
> weeks ago had destroyed the mechanism that would allow instances of ntpd to
> interoperate across the epoch 1 boundary in 2036. 

Could you please say more.  If I screwed up, I'd like to learn something from 
it.

Looking back, I should have written something about how that stuff works.  
It's in several messages but never made it to a file that got committed.

I think the old code converted l_fp to full time.  That needs a pivot.

I changed things so that there is never a conversion from l_fp to full time.  
There is a subtract done on the l_fp side.  The clock offset in l_fp is 
converted to an offset in seconds.  I think it's a double.  That eventually 
turns into a clock adjustment.  There is no explicit pivot.  There is an 
implicit pivot of the current time.

That turns into a requirement for the time to be reasonably close before ntpd 
is started.  Reasonably close is within 68 years.

That will screw up in 2038 on systems like the Raspberry Pi that don't have a 
battery backed RTC.  I see two ways to fix that.  One would be to put a pivot 
like time stamp into ntpd and early in the startup sequence, bump the clock 
if the current time is earlier than the pivot.  The other would be to run 
some other program before starting ntpd.  That program could use a compiled 
in time stamp or look in the file system or ...


This area is also tangled up with time_t being 32 or 64 bits.  We decided to 
use time_t as much as possible, expecting the environments to fix that in 
time.


-- 
These are my opinions.  I hate spam.