# apr-dev mailing list archives

##### Site index · List index
Message view
Top
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

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