Let's get rid of pivots

[Hal Murray]

hmurray at megapathdsl.net said:
> "as soon as they arrive" seems ugly to me, but maybe that's just because
> I've  been thinking of using l_fp to compute an offset and using the offset
> to  adjust the time with an effective pivot of "now". 

After thinking about it some more...

I think that doing the pivot "as soon as they arrive" is a good idea.

After a packet exchange, there are 4 time stamps; 2 local and 2 remote.  We 
get the local times as timespecs before turning them into l_fp.  We'll have 
to save those local timespecs in order to avoid a bogus pivot.

The point is that there is no pivot anywhere near the main body of 
timekeeping.  And no hidden pivot like requiring the system time to be close 
enough.

Note that the pivot time isn't critical.  Being off by a few years or even a 
few dozen is not a problem.  It would be perfectly reasonable to use the 
release date rather than the build time.  (We may want the build time for GPS 
pivot.)

We might want to include a sanity check in the pivot code.  The full range of 
32 bits of seconds is 136 years.  Most of that range doesn't make sense.  
Does it make sense to set the clock to 100 years after the build time?  More 
likely you are talking to a confused server.  Maybe that filter should be 
part of the BOGON filtering.

-------

Note that there are actually 2 packet processing paths to consider.  The 
above is the client side.  I think the server side is trivial - no pivot 
involved.


-- 
These are my opinions.  I hate spam.