apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <jwool...@virginia.edu>
Subject RE: Why not POSIX time_t?
Date Mon, 15 Jul 2002 19:48:55 GMT
On Mon, 15 Jul 2002, Bill Stoddard wrote:

> Cliff demonstrates that there is significant loss of accuracy using just a
> shift. I believe (faith? :-) that there is a simple solution to this. Don't
> know what it is just now though...

More numerical musings:

Without compensation:

1-21 seconds come out 1 too low (ie, that range maps to 0-20 seconds)
22-43 seconds come out 2 too low (ie, that range maps to 20-41 seconds)
44-... come out 3 too low, etc.
440 comes out as 419 (21 too low), etc.

The actual cutoff point is not precisely on the integral second value, of
course.

Take the number of microseconds, convert it to hex, and drop the
least-significant five digits, and that's the resulting value we're
talking about here.

So it's something close to:

realsecs = ((realusecs >> 20) + (realsecs/22) + 1);

Which simplifies out as:

realsecs = 22/21 * ((realusecs >> 20) + 1);
realsecs = 22/21 * (realusecs >> 20) + 22/21;
realsecs = 44/21 * (realusecs >> 20);

This is almost certainly imprecise for high numbers of seconds.  :)

--Cliff


Mime
View raw message