NTP time vs POSIX time

[Hal Murray]

Executive summary:
  We don't ever need 64 bits of seconds when working with the NTP epoch.

I think we need two versions/types for l_fp.  One for NTP epoch time and the 
other for offset.

There are 4 places where we need NTP epoch time, one each for the 4 time 
stamps that go into a packet.  They all start with POSIX time.  We just add 
the difference in epochs and truncate.

After processing a packet in client mode, we end up with a time offset.  32 
bits of seconds is fine for that.

Note that there is no pivot point logic.  We never convert a time from NTP 
epoch to POSIX epoch.  We are assuming that the system/POSIX clock is within 
31 bits or 68 years of correct.

We can add a sanity check during initialization that compares the system time 
with what would have been the pivot point.  It would normally bail and let 
the operator fix the clock.  Note that this check can also check for 
too-far-in-the-future.

For systems without a RTC/TOY clock and that are so brain damaged that they 
don't have any clock initialization code, we could have an option to smash 
the clock to what would have been the pivot point.  Then the normal offset 
processing will be within range.

---------

There is actually one place that needs 64 bit times in NTP epoch.  That's 
what started this line of thought.

The leap second file contains times in seconds using the NTP epoch.  The 
current code keeps things in NTP epoch.  It's really ugly.  (or maybe I just 
don't grok it.)

I think it would be much much simpler and cleaner if the conversion was done 
when the file is read in and all processing was done using POSIX time_t and 
POSIX epoch.  That read/convert step doesn't need any pivot logic because it 
can use 64 bit arithmetic.


-- 
These are my opinions.  I hate spam.