Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19280 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67504 invoked by uid 1010); 28 Sep 2005 22:57:51 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 67489 invoked from network); 28 Sep 2005 22:57:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 22:57:50 -0000 X-Host-Fingerprint: 80.74.107.235 mail.zend.com Linux 2.5 (sometimes 2.4) (4) Received: from ([80.74.107.235:33859] helo=mail.zend.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 1A/AA-54476-DEF1B334 for ; Wed, 28 Sep 2005 18:57:50 -0400 Received: (qmail 16527 invoked from network); 28 Sep 2005 22:57:44 -0000 Received: from localhost (HELO ANDI-NOTEBOOK.zend.com) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 22:57:44 -0000 Message-ID: <6.2.3.4.2.20050928155517.04710860@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 28 Sep 2005 15:57:41 -0700 To: Rasmus Lerdorf ,internals@lists.php.net In-Reply-To: <433ABE48.6050607@lerdorf.com> References: <43393A43.4070805@lsces.co.uk> <43397E48.7080107@lsces.co.uk> <43398CB6.9030808@lsces.co.uk> <433ABE48.6050607@lerdorf.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [PHP-DEV] timezones & date() breakage From: andi@zend.com (Andi Gutmans) When I agreed to commit this for PHP 5.1, Derick promised that this was going to completely keep BC. That is obviously not happening. While I appreciate his efforts, I think as with the reference change, this will cause much more widespread pain than we can even imagine. Without being an expert on this timezone stuff, I suggest to have the ability to get the old behavior, wether it's reverting to the system date, either if we can't find the timezone entry, or if that is a problem due to overlaps, then have a setting which allows to get the old behavior. I don't even mind if it's called date.old_broken_timezone_behavior. We did something similar in oci8 in order not to break apps. Andi At 09:01 AM 9/28/2005, 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. > >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. > >His new date() code is obviously better and more portable than what we >had. So it comes down to a pretty simple decision that doesn't need all >that much emotion poured into it: > > Do we take the BC hit now to get clean and consistent date/time > handling or do we stay with the BC over all else path we usually > take? Either way we have pain. If we break BC there will be plenty > of pain from very vocal users who feel personally wronged that we broke > their code, and if we don't break BC and go with two different > date/time systems we have to live with these two systems forever and > it we will need to hold up the 5.1 release for a couple of weeks. > >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. > >-Rasmus > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php Zend/PHP Conference & Expo Power Your Business with PHP October 18-21, 2005 - San Francisco http://zend.kbconferences.com/