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 Fri, 29 Jun 2001 07:11:54 GMT
What's with the HTML email????

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

yeah, I was going to write them all and ended up pasting in some stuff from
apr_time.h, sorry :)  Glad it didn't confuse you :)

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

Why should it be fixed???

>
> >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.
> >
> Actually, what was happening is something like this:
>
>     apr_time_t old, new;
>     apr_exploded_time_t xt;
>     apr_time_now(&old);
>     apr_explode_localtime(&xt, old);
>     apr_implode_time(&new, &xt);
>     if (old != new)
>        it's a bug!

Yeah, but that's what we expect!  It's not a bug!  If you call
apr_time_now() you get GMT!  That's the basic problem in your logic - apr
will normally work in GMT as that's a sensible (the only really sensible)
starting point.  What you're saying is

- get GMT time as old
- get localtime based on GMT
- if gmt != localtime - it's a bug!

Unless you live in gmt_offset = 0 then it'll always be different!  In fact
most places in the gmt_offset use DST and so it'll be different for half the
year anyway!

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

Why?  You don't like participating in discussions? :)  It's more use face to
face 99% of the time.

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

Nope.  Sorry but in that case we wouldn't need 3 different implementations
would we?  apr_time_now gives back GMT.  apr_explode_localtime does just
that - gives localtime.  If you want GMT use apr_explode_gmt (as testtime
does) and it'll work as you expect.

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

If that's the case then Win32 is broken, so once again Unix rules :) I'm
surprised though as Bill Rowe was the main collaborator in these changes!

>
> I'll look into fixing this.
>

Don't think it's broken, but the documentation probably needs to be improved
on.

david



Mime
View raw message