httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: ap_current_time() is not intuitive
Date Wed, 05 Jan 2000 16:41:16 GMT

It's confusing because you are looking at things in the middle of being
finished.  The problem is I wrote the file stuff before the time stuff,
and I haven't had a chance to go back and fix the file stuff yet.  I am in
the middle of doing it, but I have an awfull lot going on right now.
Perhaps if I outlined what is currently happening.

ap_get_fileatime is going away completely.  In fact, most of the
ap_get_file* functions are going away, because the stat structure is not
going to be an opaque type anymore.

The APR stat structure will look something like:
    ap_fileperms_t protection
    ap_uid_t       user
    ap_gid_t       group
    ap_off_t       size
    ap_time_t      *atime
    ap_time_t      *mtime
    ap_time_t      *ctime

These will be directly accessable.  If you want the atime, you will do:
    ap_stat(ap_finfo_t, fname)
    atime = ap_finfo_t->atime

> which uses the unix time_t.
> and you've also got:
>   ap_status_t ap_get_curtime(ap_time_t *, ap_int64_t *);
> which uses an unnamed type!

This needs to be fixed.  Plain and simple, I had a discussion with Bill
about this yesterday.  This will officially be the ansi time type, and
this will be specified.  

Basically, the ap_time_t structure will remain the same, on Unix:
    struct timeval   /* I need to remember why I didn't use time_t, but I
                        think it had to do with some of the current Apache
                        functions. */
    struct tm;
When we get the current time, we will fill out the struct timeval. When we
explode it, we fill out the struct tm with either localtime or gmtime.

On Windows:

When we get the current time, we fill out the SYSTEMTIME, when we implode
it, we will convert it to an ansi time.

> i think we should take another hint from NSPR here (see
>, and we should
> have:
>   /* microseconds since the epoch (00:00:00 jan 1, 1970 UTC) */
>   typedef ap_int64_t ap_time_t;
> and
>   /* "exploded time" ... or use another name for it */
>   struct ap_tm ap_tm_t;
> the exploded time is really only for human consumption, it shouldn't be
> the default returned by functions such as "time(0)" or whatever the "get
> the time now" function happens to be.  that's far too much computation for
> such a commonly used function.

Could you please tell Microsoft that, because the only function I have
found to do get the current time on a system is GetSystemTime, and that
returns the equivalent of an expanded time on Windows.

In order to do what you want, I have to basically call GetSystemTime, and
then convert it to what Windows calls a FILETIME (# of 100-nanosecond
blocks since some date in the 1600's), and then convert that into an ansi
time value.  I would rather not have to do all of that.

> the functions such as ap_get_fileatime would take an ap_time_t *, and
> there would be a function equivalent to time(0) for getting the current
> time as an ap_time_t.

If we were just unix, this is how I would have designed it, we aren't.  I
was trying to make a good attempt at improving performance on Windows.

I really don't care right now how we do it.  But please do not look at the
fact that we aren't using ap_time_t's all over the place to mean they
aren't good enough, they just weren't written yet when I had to have some
time values.


Ryan Bloom
4205 S Miami Blvd	
RTP, NC 27709		

Come to the first official Apache Software Foundation
Conference!  <http://ApacheCon.Com/>

View raw message