apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: apr_implode_time and time zones
Date Thu, 28 Jun 2001 16:48:05 GMT
I've reviewed the code and can't quite see what you mean...

> >I believe this is a bug.  However, we have never been able to reliably
> >it.  You should check the APR list archives, because David Reid and I
> >discussed this a while back.  It was probably around March of this year.

Read on...

> >
> Hmm. Couldn't find anything there ...
> >You could also check CVS for the logs for the time code on Unix.  That
> >would give you a better idea of when we had the discussion.
> >
> All I saw was something about tm_gmtoff not being present on Solaris.
> But there's already a workaround for that, isn't there?
> I fail to see how apr_implode_time() could /ever/ be wrong if it uses
> tm_gmtoff. Whether that field is set correctly or not is another matter,
> and most probably shows up only on very few platforms. Right now,
> apr_implode_time() is /always/ wrong. Surely it sould be a lesser evil
> to just fix it?

OK, basically apr_implode_time ONLY works with an apr_exploded_time_t.  We
have a number of ways of getting one of those,

 * convert a time to its human readable components using an offset
 * from GMT
 * @param result the exploded time
 * @param input the time to explode
 * @param offs the number of seconds offset to apply
* @deffunc apr_status_t apr_explode_time(apr_exploded_time_t *result,
apr_time_t input, apr_int32_t offs)
APR_DECLARE(apr_status_t) apr_explode_time(apr_exploded_time_t *result,
                                           apr_time_t input,
                                           apr_int32_t offs);

 * convert a time to its human readable components in GMT timezone
 * @param result the exploded time
 * @param input the time to explode
 * @deffunc apr_status_t apr_explode_gmt(apr_exploded_time_t *result,
apr_time_t input)
APR_DECLARE(apr_status_t) apr_explode_gmt(apr_exploded_time_t *result,
                                          apr_time_t input);

 * convert a time to its human readable components in local timezone
 * @param result the exploded time
 * @param input the time to explode
 * @deffunc apr_status_t apr_explode_localtime(apr_exploded_time_t *result,
apr_time_t input)
APR_DECLARE(apr_status_t) apr_explode_localtime(apr_exploded_time_t *result,
                                                apr_time_t input);

Basically, the first will always give GMT/UTC (0 offset), the next will give
localtime (offset set accordingly) and the final gives GMT/UTC +/- the
offset you pass in.  The time recorded in the various parts of the structure
is that of the time with the offset applied - hence applying it again is
evil and wrong!

The part that was probably giving you problems, although you don't describe
what problems you were seeing, was the code that takes an ostime structure
and morph's it into an apr_exploded_time_t, which ignores the gmt_offset at
present.  However, I have a fix for that and some code cleanup on the way as
soon as I get a connection I can commit via (in Bahrain for another 4 hours
or so before going home so not long to wait).  AFAICT there's no way to
figure out how to set the gmt offset on Solaris when passing in a value, but
if you want localtime simply use apr_explode_localtime and you'll get it
that way.

This was what we decided at Santa Clara was the way we'd do the time zones.
When I raised the question there were probably 50% of the active APR folks
in the room :)


View raw message