> From: "Cliff Woolley" <cliffwoolley@yahoo.com>
> Sent: Thursday, February 15, 2001 1:36 PM
>
>
> > I guess I won't argue this too loudly if people agree that apr_interval_time_t's
> > definition is flexible)...
>
> It is _NOT_ flexible [your definitions are correct below].
>
> > While up_time does represent a value related to time, neither apr_time_t nor
> > apr_interval_time_t is strictly appropriate:
>
> I agree
>
> > apr_time_t is defined to be a value in microseconds since the epoch... this
> > usage meets neither criteria and is clearly not the best choice.
> >
> > apr_interval_time_t is defined to be a value *in microseconds* that is the
> > difference between two apr_time_t's... this usage doesn't meet the first
> > criterion in that it's not in microseconds; furthermore,
> > apr_interval_time_t's are limited to representing intervals of about 70
> > minutes or so given the number of microseconds that can be represented in 32
> > bits, meaning that apr_interval_time_t's are really only useful for
> > representing timeouts which are generally much less than 70 minutes. If we
> > choose to be flexible about whether an apr_interval_time_t is in
> > microseconds or seconds, then I guess this isn't a big deal... but I'll
> > leave that up to you all to argue amongst yourselves. =)
>
> +/ 35 minutes or so, your 70 minutes is based on an unsigned, which this isn't.
>
> I will _veto_ any abuse of apr_interval_time_t or apr_time_t in a manner that isn't
> consistent with the definitions you cited above.
Guys, we have a time value that doesn't fit as either of these. Either we
need ANOTHER time type, or we have done something wrong.
Please do not tell me:
apr_time_t  apr_time_t != (apr_time_t  apr_interval_time_t)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131

