Time to slow down and be more careful

[Hal Murray]

> I didn't "add" a damn thing.  I restored the pivot computation that was
> there before it was mistakenly removed.  You can compare the Classic version
> to check this; there are some superficial differences due to the l_fp and
> macro cleanups but the logic is the same. 

> Mills's solution was to map the timestamp to whichever of these aleph-0
> possibilities is closest in time to a pivot.  Then, if the time intended by
> the sender was within a half-cycle of the pivot, all is good.  That's what
> this code is doing. 

OK, I think I'm catching on.

That code you restored is crap.  It takes an offset, converts it to a l_fp, 
gets the system time in l_fp, adds them together, then converts it back to a 
system time.  Due to the small range of an l_fp, that convert back step needs 
a pivot time.

That pivot will catch starting up in 2039 on systems without RTC.

Before your recent restore, step_systime did a pivot around "now".  That 
works correctly once it gets started.

I've said several times that we depend on the current time to be reasonable.  
The no-RTC case is a good way to get an unreasonable time.

I see two ways to handle the no-RTC case.

One is to run some other program before starting ntpd.  It could use the 
build date or file system or whatever to set the system time to a reasonable 
value.  My straw man for a file would be the leap seconds file.  That's 
assuming it won't get updated when the system has a bogus time and/or the 
update process will preserve the time stamps.  (We need to handle the 
no-leap-second file case too.)

The other would be to but a sanity check early during startup of ntpd.  If 
the system time is less than the build date, bump it up.

Either way could also check for time unreasonably far into the future.


-- 
These are my opinions.  I hate spam.