Pivoting (or rather missing pivot)

Hal Murray hmurray at megapathdsl.net
Thu Apr 27 20:07:58 UTC 2017


>> Which problem do you think we are discussing?
> The bad reversion is what I am discussing. 
 OK.


>> step_system works as you describe it.  The problem is that it is
>> being fed bad data.
> Really?  Can you detail your assertion? 

How about an example?

System time is 1970.  Server time is 2037, which gets truncated and turns 
into 1901
Subtract gives an offset of -69

> No.  It thinks it does a pivot, but you never pivot an offset, only a
> timestaamp. 

Get the currect system time.  Add the offset.  Now you have a timestamp for 
the new system time.  Pivot that.

Using the above example, the new time would be 1901 which is before the build 
date so add 136 years to get 2037, the server time that we want.


>                    When you subtract one timestamp (with the implicit term
> NTP_EPOCH) from another timestamp (with th eimplicit NTP_EPOCH) then you
> have removed the term NTP_EPOCH. 

Right.  But in the l_fp case, one or both of the timestamps may have been 
truncated.

One truncation isn't fatal.  Consider 2035 and 2037.  After truncation, the 
2037 is 1.  When you do the subtract, there is an overflow which in this case 
adds the truncation back.

The nasty cases are one truncation and no overflow or overflow with no 
truncation.

That's assuming you do the subtract using 64 bit arithmetic.  If you use 
something bigger, you don't get the overflows.  That fixes one case but 
breaks one that used to work.


> See above.  No pivot needed.  Subtracting one timestamp from another removes
> any constant that is in both terms. 

Right.  But it doesn't magically fix unmatched truncations or overflows in 
the subtract.



-- 
These are my opinions.  I hate spam.





More information about the devel mailing list