Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19281 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81891 invoked by uid 1010); 28 Sep 2005 23:56:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 81875 invoked from network); 28 Sep 2005 23:56:26 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 23:56:26 -0000 X-Host-Fingerprint: 84.56.8.67 dsl-084-056-008-067.arcor-ip.net Received: from ([84.56.8.67:20200] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 56/BB-54476-7AD2B334 for ; Wed, 28 Sep 2005 19:56:24 -0400 To: internals@lists.php.net Date: Thu, 29 Sep 2005 01:56:18 +0200 Message-ID: <20050929015618.0cb055c6@localhost.localdomain> References: <43393A43.4070805@lsces.co.uk> <43397E48.7080107@lsces.co.uk> <43398CB6.9030808@lsces.co.uk> <433ABE48.6050607@lerdorf.com> X-Newsreader: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Posted-By: 84.56.8.67 Subject: Re: [PHP-DEV] timezones & date() breakage From: pierre@dotgeek.org (Pierre) On Wed, 28 Sep 2005 09:01:12 -0700 rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > This discussion has been interesting. ;) > > These sorts of problems have come up many times during the course of > PHP development. Things that were implemented to solve a very > specific local problem ended up causing grief when the scope of PHP > grew. Think of things like magic_quotes_gpc and case-insensitive > function names. Both of these actually made perfect sense when they > were implemented but as things got bigger they started to get in the > way and today most people wish we had broken backwards compatibility > a long time ago and gotten rid of those early on. Except that one should listen to valid concerns and not commit anything to a feature freezed branche. Sorry to say it again and again, but I'm really pissed off by this attitude. > We have tended towards not breaking BC over the years leaving quite a > bit of cruft around for people to deal with. Watching Derick try to > buck that trend has been fun and I think he deserves a bit less > vitriol for his efforts. I prefer some ears vacuum cleaner. > I actually lean more towards the keeping BC side here but was hoping > the new date implementation could get to the point of minimal BC > breakage or perhaps even none with some sort of compatibility mode. > I think there is a lot to be said for not having two different > implementations so for the folks who feel so strongly about this, > pitch in with some testing and help make this new implementation > backward compatible. It should be possible to get this timezone > mapping to the point where it addresses the majority of timezone name > overlaps in the world. The problem is to prevent the points of failures, to provide a BC fix for each of them. It could be possible if we have a way to tests and compare the 4.x - 5.0.x behaviors with Derick implementations, but we have nothing but a huge amount of suppositions. As I said, I doubt we can delay again 5.1.0 for some more weeks. Unless we drop all the Derick's changes and restore the previous codes, I doubt we have enough time to find a valid solution or implement any fancy tags. --Pierre