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