Timezones logic...

[David Reid <dr...@jetnet.co.uk>]

In the recent discussions about implode/explode time it became obvious that
the documentation (such as it is) isn't very clear on why we do things the
way we do...  This I will attempt to solve by this email.

We wrote the apr_implode_time routine to take an exploded time structure
(that is an APR only structure) and create a time_t from it.  There is no
reason why this time_t needs to be in any particular time zone, in fact it's
often desirable to be able to choose the time zone.  That's what we provide
through the apr_explode_time and apr_implode_time functions.

Simple example.

This is something else on my todo list...  Basically allow each vhost on the
server (apache) to have a timezone setting given to it.  This is then used
when generating access log entries from that vhost, though not error_log
messages.  The process becomes very simple with the functions we have...

during the request we get the time by calling (pseudo code)
t = apr_time_now();

then when we write out to the access log instead of one line we have...
apr_explode_time(&xt, t, vhost->offset);
apr_strftime(str, str_size, max_str_size, "fmt", xt);

This is quick and easy and makes sense (I hope) to everyone reading it.  Yes
it is server oriented but then it also works for client apps.  Brane's
addition of apr_implode_gmt helps with those apps that demand a GMT/UTC
time.

Now if anyone wants to do something fancy with the time (don't know what
that would be) we can always get a time_t from that exploded time using just
apr_implode_time, which will give us the correct time, i.e. the time that
we've just written into the log.  If the time returned by apr_implode_time
was different I'd say we had a bug!

That's why we have done things the way we have, and hopefully that makes
people happier about why.  I've written this as I probably won't get time to
change the docs anytime soon, so if anyone else wants to then please feel
free.

david

Re: Timezones logic...

[David Reid <dr...@jetnet.co.uk>]

> hiya david,
>
> i just want to double-check something.  i got caught out by
> creating cookies of 1 year which actually turned into 30 seconds
> because apr_time_t is in microseconds :) :)
>
> so, could you confirm at the points below for me?   thanks
>
> also, i should point out some experience from seeing over-the-wire
> stuff from SMB, which may be relevant to NT.
>
> > We wrote the apr_implode_time routine to take an exploded time structure
> > (that is an APR only structure) and create a time_t from it.  There is
no
>                                                ^^^^^^
>
> do you mean a time_t or do you mean an apr_time_t?  the external
> interface is apr_time_t.

ok, it's an apr_time_t that should be a time_t on most platforms...

>
> you are referring to internal implementation details, yes?

Yes.

>
> > This is quick and easy and makes sense (I hope) to everyone reading it.
Yes
> > it is server oriented but then it also works for client apps.  Brane's
> > addition of apr_implode_gmt helps with those apps that demand a GMT/UTC
> > time.
>
> okay.

Cool.

>
> microsoft's implementation of GMT over-the-wire is... uhhh...  wrong!
> [they couldn't even implement a well-known algorithm correctly, having
> used localtimes for years.  and of course, once released, they have
> to _keep_ it because it's too late by then, you and everyone else
> and their mothers have to be backwards-compatible with KludgeGMT...]
>
> what they actually do is reverse-convert-back from localtime, but
> they do it at the wrong times, such that for about a day or so
> around daylight saving time changes, GMT goes haywire +/- one hour.
>
> it may be time well worth spent investigating whether the top-level
> NT API that gives you GMT is as equally broken or not w.r.t file
> timestamps and time creation. etc.  or whether you have to do
> the conversion _correctly_ yourselves.

Well, as I don't have a compiler for windows (anyone wants to supply one I'm
game) then this will have to wait for Bill or OtherBill to sort out.  No
wonder NT is so messed up.

david
(in Dubai where it's way too hot and sticky)

Re: Timezones logic...

[Luke Kenneth Casson Leighton <lk...@samba-tng.org>]

hiya david,

i just want to double-check something.  i got caught out by
creating cookies of 1 year which actually turned into 30 seconds
because apr_time_t is in microseconds :) :)

so, could you confirm at the points below for me?   thanks

also, i should point out some experience from seeing over-the-wire
stuff from SMB, which may be relevant to NT.

> We wrote the apr_implode_time routine to take an exploded time structure
> (that is an APR only structure) and create a time_t from it.  There is no
                                               ^^^^^^

do you mean a time_t or do you mean an apr_time_t?  the external
interface is apr_time_t.

you are referring to internal implementation details, yes?

> This is quick and easy and makes sense (I hope) to everyone reading it.  Yes
> it is server oriented but then it also works for client apps.  Brane's
> addition of apr_implode_gmt helps with those apps that demand a GMT/UTC
> time.

okay.

microsoft's implementation of GMT over-the-wire is... uhhh...  wrong!
[they couldn't even implement a well-known algorithm correctly, having
used localtimes for years.  and of course, once released, they have
to _keep_ it because it's too late by then, you and everyone else
and their mothers have to be backwards-compatible with KludgeGMT...]

what they actually do is reverse-convert-back from localtime, but
they do it at the wrong times, such that for about a day or so
around daylight saving time changes, GMT goes haywire +/- one hour.

it may be time well worth spent investigating whether the top-level
NT API that gives you GMT is as equally broken or not w.r.t file
timestamps and time creation. etc.  or whether you have to do
the conversion _correctly_ yourselves.

all best,

luke