Richard Lynch wrote:
>What is the least-stupid way to fix this, and get 20:00 in the
>Portland OR server to turn into:
>Mon, 03 Apr 2006 20:00:00 CDT
>which is what time it really was.
>
>Errrr. Without changing the schema which means having to re-do
>everything else in the application. That's probably the RIGHT way to
>fix it, but that ain't happening.
>
>
Yeah... I ran into the same stuff a few weeks ago with the DST change.
The quickest solution that is *almost* OK is using
putenv("tz=america/montreal") or putenv("tz=america/san_diego") etc..
(should really be the date_default_timezone_get/set functions)
Datetime fields do not have timezone stored (mysql too.) The only real
solution to this problem is to always store datetimes in GMT/UTC. That
is the correct thing to do, and until that is done our workaround still
has one problem (that isn't big enough to warrant reworking the
ticketing code that inserts to the db...)
The remaining problem is that until we store in UTC we will never know
which 01:30:00 a timestamp refers to, EDT or EST (Eastern Daylight, or
Eastern Standard.) In UTC this doesn't happen. Of course there is no
problem for spring, only in the fall time change.
This can be a big problem to some apps, and others might be fine with
the workaround like we've done where you loose a tiny bit of data (It's
08:00 on the day after the timechange, is this ticket from 01:30:00 6.5
or 7.5 hours old? who cares.. just reply.)
Travis Doherty
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
