apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: apr_time_t --> apr_time_usec_t
Date Tue, 11 Jun 2002 02:31:07 GMT
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



Mime
View raw message