Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19518
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <011101c5cc40$842d1f10$0100a8c0@pc07653>
To: "Christian Stocker" <christian.stocker@bitflux.ch>,
	"Zeev Suraski" <zeev@zend.com>
Cc: <internals@lists.php.net>
References: <5.1.0.14.2.20051008152435.09df8390@localhost> <4347CD3D.5000302@bitflux.ch>
Date: Sat, 8 Oct 2005 20:43:11 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Timezone stuff - conclusion
From: nlopess@php.net ("Nuno Lopes")

> On 8.10.2005 15:30 Uhr, Zeev Suraski wrote:
>> I've been away from email for the last couple of weeks - read through
>> the timezone thread, and didn't really see a conclusion.
>
> IIRC the conclusion was, that Derick tries to make the TZ detection
> better (which was the only BC problem, AFAIK). And according to him,
> that's now almost solved (except some weird problems on Windows).

Yep, even on windows is it almost working at 100% :) And I'm having much 
more success with the new code, specially on Windows and Solaris.


> He even made a pecl package for updating the TZ data easily should that
> change.

Upgrading the TZ data should be as easy as upgrading a PECL package.


> If the TZ detection works reliable, I don't see any reason to revert or
> postpone Dericks work, the timezone handling of his implementation is so
> much better than the old one, it's really worth the upgrade for everyone
> having to deal with different timezones.

Yes it shouldn't be reverted. I think it is working well, and it is already 
covered by a large amount of test cases, so the BC breaking chances are 
minimal.

Nuno


> Just my 2 cents.
>
> chregu
>
>>
>> My suggestion is to restore the old code in its entirely, and introduce
>> the new implementation as new functions with a proper prefix, a-la PHP
>> 2005.  I think it's better than an INI entry, and it should be fairly
>> straightforward to implement.
>>
>> I don't think anybody is underestimating Derick's efforts towards
>> building this new date functionality.  I certainly don't.  I also don't
>> see any reason to break compatibility in something as basic as this, so
>> this should be introduced either as a new (preferably) or optional (less
>> preferably) feature.
>>
>> Zeev