Cameron, Steve writes:
>
> Larry Jones wrote:
> >
> > Correctly doing the conversion on the server side would require passing
> > all of the timezone information -- including the Daylight Saving Time
> > rules -- from the client to the server in some kind of portable fashion,
> > which I currently don't know of any way to do.
> [smc] By portable fashion, you mean, wihtout
> doing time_t arithmetic and without assuming
> time_t's are in seconds, right?
No, I mean that the mapping between UTC and local time is very
complicated if the local timezone has, or has ever had, some sort of
Daylight Saving Time or Summer Time (which I'll abbreviate as DST from
here on). If you just compute the difference between UTC and local time
(LT) *right now* and apply that to all the times, you won't get the
right results -- if DST is currently in effect, the results will be as
if DST were *always* in effect; likewise, if DST isn't currently in
effect, the results will be as if DST were never in effect. What you
want is to have the results switch back and forth between standard time
and DST as appropriate. That means that the client has to be able to
tell the server everything there is to know about how DST works in its
local timezone -- when it starts, when it end, and what the adjustment
is (as far as I know, everyone who currently has DST adjusts by one
hour, but there have been other adjustments in the past and there will
probably be more in the future). Since DST is determined by politicians
rather than engineers, there usually isn't just one rule, but lots of
rules that apply for varying periods of time. Now, for gmtime() and
localtime() to work correctly, the client system has to know all this
information, but there isn't any portable way of obtaining it or
specifying it, nor is there any generally agreed upon format for
transmitting it from one system to another (e.g., from the client to the
server). As you noted, different systems don't even name timezones the
same way let alone agree on how all the rules are represented.
So, I think the conversion has to be done on the client side, since
that's the only place that has sufficient information to do the
conversion correctly.
> So, how about this:
[algorithm snipped]
That's similar to what the history code currently does, although it uses
getdate() rather than mktime() and assumes time_t is in seconds. It has
the problem I mentioned above -- the results are as if DST were always
in effect or never in effect depending on which it is right now.
-Larry Jones
If I get a bad grade, it'll be YOUR fault for not doing the work for me!
-- Calvin
