[EMAIL PROTECTED] wrote:
On Tue, 13 Aug 2002, Brian Pane wrote:
[EMAIL PROTECTED] 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.
Agreed, apps should be using separate functions to format time_t than
they use for apr_time_t.
To use time_t in a portable app, though, I expect that we'll still
need to rely on APR to provide a portability wrapper. The code for
even simple things like getting the current time is different between
Unix and Win32. (I wouldn't mind leaving apr_time_t as-is if we
also had a portable second-resolution time API to complement it.)
As for the file stat fields, just move those to time_t instead of
apr_time_t, and the problem goes away too.
I'm definitely in favor of changing those to time_t.
Brian
