At 09:15 PM 6/10/2002, you wrote:
William A. Rowe, Jr. wrote:
>
> >apr_time_t must be in seconds. If folks want APR to keep time in
> >microseconds, then they had bloody well change the type name
> >accordingly.
>
> apr_time_t must nothing :-) Let's discuss *should(s)*
>
> time_t is seconds. I love the idea of apr_time_usec_t and apr_time_sec_t
> names rather that something as ambigous as apr_time_t (which is misleading,
> I agree.)
>
Agreed. But, IMO, it *is* documented that apr_time_t is microsecond
resolution. If people make assumptions then, well, that's bad, but
not really a showstopper as far as I'm concerned.
Now the nastyness of 64bit mult/division when we (always) need second
resolution is another. Sure would be nice if it was an exact power of 2 :)
It can be. busec [binary microseconds] has a resolution of 1 / 2^20,
leaving 2^41-1 for minutes [and providing for negative time.] That yields
69000-some years forwards or backwards from Jan 1 1970.
busec translation would be pretty trivial...
time >> 20 == seconds
time && (2^20 - 1) == busec (binary microseconds)
usec * 1048575 / 1000000 = busec
bsec * 1000000 / 1048575 = usec
The nice thing is that you can do all the addition, subtraction and
multiplication you want and come back to seconds/usec values
anytime you like. You don't need to perform separate math operations
with carry on two separate fields, which is the significant fault to the
sec, usec structure case.
The question is, how often do you need to convert usec between
decimal and binary? Really only to implode or explode the time, either
in display/gregorian format or sec/usec structures.
Just some boolean food for thought.
Bill
