Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19257 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36668 invoked by uid 1010); 28 Sep 2005 12:52:53 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 36646 invoked from network); 28 Sep 2005 12:52:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 12:52:53 -0000 X-Host-Fingerprint: 82.94.239.5 jdi.jdi-ict.nl Linux 2.5 (sometimes 2.4) (4) Received: from ([82.94.239.5:34412] helo=jdi.jdi-ict.nl) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 00/9F-54476-1229A334 for ; Wed, 28 Sep 2005 08:52:50 -0400 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.12.11/8.12.11) with ESMTP id j8SCqjkY002877; Wed, 28 Sep 2005 14:52:45 +0200 Received: from localhost (localhost [127.0.0.1]) by jdi.jdi-ict.nl (8.12.11/8.12.11) with ESMTP id j8SCqdYn002870; Wed, 28 Sep 2005 14:52:41 +0200 Date: Wed, 28 Sep 2005 14:52:37 +0200 (CEST) X-X-Sender: derick@localhost To: Stanislav Malyshev cc: PHP Developers Mailing List In-Reply-To: Message-ID: References: <43393A43.4070805@lsces.co.uk> <43397E48.7080107@lsces.co.uk> <43398CB6.9030808@lsces.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at jdi-ict.nl Subject: Re: [PHP-DEV] timezones & date() breakage From: derick@php.net (Derick Rethans) On Wed, 28 Sep 2005, Stanislav Malyshev wrote: > DR>>But you do need UTC somewhere, as *all* date code (OS, applications) > DR>>use UTC timestamps to calculate the current time. > > So? They are able to use it transparently without requiring me to do any > special configuration for each application - they just go out and display > the right date. Only PHP 5.1 needs separate configuration for that. This > is broken. I wouldn't call it broken, just less inituitive. But besides that point, I looked at some data and have a patch that allows the timezone guessing code to also check against the GMT offset, and not only the abbreviation. This means that with these DB entries: { "idt", 1, -HOUR ( 3), "Asia/Tel_Aviv" }, { "idt", 1, -HOUR (4.5), "Iran/Teheran" }, { "idt", 1, -HOUR (6.5), "Asia/Calcutta" }, IDT will be recognised correctly for all three variations. There are two ways of creating the database for this: 1. by iterating over the timezone database and collecting all the possible combinations 2. by copying the data from http://www.worldtimezone.com/wtz-names/timezonenames.html I think option 1 is the better here, and I'll play with a script to generated that data tonight. After that I'll commit the patch too. I think this shoul adequately solve the problems that you encountered. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org