Can you get from there to a time_t or struct tm? Then you can build a
CTime from that, right?
On Wednesday, April 11, 2001, at 02:30 PM, Bill Stoddard wrote:
> LLONG_MAX is not defined on Windows. And I still get 16 warning
> message, about
> the same as before applying the patch.
>
> Bill
>
>> On Wed, Apr 11, 2001 at 12:11:02AM -0400, Cliff Woolley wrote:
>>> apr_time_t (64 bits) is reserved for values that represent time *in
>>> microseconds* from Jan 1, 1970. Time offsets in microseconds can be
>>> represented with apr_interval_time_t (64 bits) or
>>> apr_short_interval_time_t (32 bits).
>>
>> Ah, now that I look at it, I also used apr_off_t incorrectly. I'm not
>> even
>> sure why I used apr_off_t. Switched to apr_interval_time_t where
>> appropriate. I guess I was thinking of file offsets, not time offsets.
>>
>>> If you want to represent absolute time or relative (interval) time in
>>> seconds or milliseconds, you should just use apr_int64_t or
>>> apr_int32_t.
>>
>> Is using apr_int64_t preferred to using apr_interval_time_t? Also,
>> wouldn't there be some problems if you take an apr_time_t and subtract
>> another apr_time_t and stick the result in a 32-bit value? This is
>> what
>> was implicitly happening on Solaris/Sparc - which caused all of the
>> calculations to go haywire.
>>
>>> Alternatively, you could rearrange the conversions to/from
>>> microseconds in
>>> your code so that the values are stored and manipulated in
>>> microseconds
>>> (in which case the use of apr_time_t and apr_interval_time_t are
>>> fine) and
>>> you don't convert to seconds/milliseconds until "the last minute" (eg,
>>> when you go to print out the results).
>>
>> Parts of ab do this, and parts don't. Some of the calculations are
>> done
>> as it happens and some of them are delayed until after the run. It
>> wasn't
>> my intention to rework ab - just get it working again.
>>
>
>
>
