At 02:13 PM 7/11/2002, Brian Pane wrote:
William A. Rowe, Jr. wrote:
apr_int32_t apr_time_sec_get(time) deprecates apr_time_sec(time)
apr_int32_t apr_time_msec_get(time) deprecates apr_time_msec(time)
apr_int32_t apr_time_usec_get(time) deprecates apr_time_usec(time)
apr_int32_t apr_time_nsec_get(time) deprecates apr_time_nsec(time)
Oh no, I just recently finished changing all the code to use
those now-deprecated macros. :-)
I know... but there are two different 'things'...
apr_int64_t apr_time_as_sec(time)
apr_int64_t apr_time_as_msec(time) or apr_time_as_272yrs_msec(time)
apr_int64_t apr_time_as_usec(time) or apr_time_as_3mos_usec(time)
apr_int64_t apr_time_as_nsec(time) or apr_time_as_2hrs_nsec(time)
The naming convention is way too subtle:
apr_time_[unit]_get means 32-bit
apr_time_as_[unit] means 64-bit
WRONG! apr_time_msec_get(time) gets the fractional component
of time... e.g. 32500.15 seconds would return 150 msecs..
apr_time_as_msec returns the entire time value! So we end up with
a time of 32,500,150 in msec's. That's why these are int64.
How often do you anticipate that people will be using the
32-bit versions? If it's not very often, then I'd rather
just supply the 64-bit versions in the API, because those
are the safe ones (no Y2038 problem). People who really
need to do 32-bit math for performance reasons would have
to cast explicitly, but IMHO that's good because it forces
them to think more carefully about whether the loss of
precision is safe.
The 32bit flavor of sec, vs. a 64 bit flavor is a simple way of
avoiding casts in the user's code. I'm only asking for the number
of seconds in an apr_time_t in order to set a time, calculate a
difference, etc. But I don't care too much, one way or the other.
apr_time_as_sec gives me a HUGE number of seconds to work
with as an absolute time from 1/1/70. That must remain 64bit.
Bill
