apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: apr_implode_time and time zones
Date Thu, 28 Jun 2001 18:42:20 GMT
David Reid wrote:

>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. 
(I think you mixd up first/last here, but so far so good).

> 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!

Hmm, good point. But that's easily fixed, I think.

>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
Actually, what was happening is something like this:

    apr_time_t old, new;
    apr_exploded_time_t xt;
    apr_explode_localtime(&xt, old);
    apr_implode_time(&new, &xt);
    if (old != new)
       it's a bug!


>  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.
But set_xt_gmtoff_from_tm already has a workaround for the solaris problem.

>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 :)

Hm. Good thing I wasn't there, then. :-)

I think what this boils down to is that the explode/implode 
implementation is wrong. The result of an implode should always be the 
same as the original time before the explode, regardless of what we told 
explode to use as the offset.

AFAIK the Win32 implementation does this correctly. Now, we wouldn't 
want APR on Win32 to be more correct than APR on Unix, would we? :-)

I'll look into fixing this.

Brane ─îibej
    home:    <brane@xbc.nu>             http://www.xbc.nu/brane/
    work:    <branko.cibej@hermes.si>   http://www.hermes-softlab.com/
      ACM:   <brane@acm.org>            http://www.acm.org/

View raw message