apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@apache.org
Subject Re: cvs commit: apr-site versioning.html
Date Tue, 13 Aug 2002 23:15:24 GMT
On Tue, 13 Aug 2002, Brian Pane wrote:

> rbb@apache.org wrote:
> >I continue to state that APR's time format should stay as it is.  If you
> >want seconds, use time_t.  The only change that I can see as appropriate,
> >is to make the interval_time_t a 32-bit value, which would mean that any
> >arithmetic on the intervals would be faster.  Apache, doesn't want (or
> >need) microsecond resolution, so it should use time_t, which
> >co-incidentally is now very easy to translate into an apr_interval_time_t
> >very quickly.  Since most, if not all, of the apr_functions should be
> >using apr_interval_time_t for the arguments, converting types should be
> >minimal.
> >
> That almost works, except that APR forces client apps to use
> apr_time_t.  All the time formatting functions and file stat
> related functions, for example, use apr_time_t rather than
> time_t.  These functions have no need for microsecond resolution,
> but at the moment they force the app to use a microsecond based
> time.

The time formatting features are for apr_time_t, and should require
microseconds.  If you want to use time formatting functions for seconds,
then you have to use the ANSI standard functions.  Essentially, using a
time_t in an apr_time_t function just won't work, and it shouldn't
work.  As for the file stat fields, just move those to time_t instead of
apr_time_t, and the problem goes away too.


Ryan Bloom                        	rbb@apache.org
550 Jean St
Oakland CA 94610

View raw message