Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19282 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83481 invoked by uid 1010); 28 Sep 2005 23:58:35 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 83466 invoked from network); 28 Sep 2005 23:58:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 23:58:35 -0000 X-Host-Fingerprint: 64.233.184.193 wproxy.gmail.com Linux 2.4/2.6 Received: from ([64.233.184.193:58390] helo=wproxy.gmail.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id EA/EB-54476-62E2B334 for ; Wed, 28 Sep 2005 19:58:30 -0400 Received: by wproxy.gmail.com with SMTP id i21so40030wra for ; Wed, 28 Sep 2005 16:58:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=INJsLwNwFkGLfDKS16py7Z3n+BpYJ6GLhkh5rT1KZaXXvoj4lkv+5nEDh6QBqMLmSJWXdOPpJMWOoHKyV9kaqJG8wikK/6CHvGrlEfCmNpBI0bpFTYx2bqnDtJFhBp9p4c69mGfpYL0uHEh7loXbPtWFpuptGZ7nc8hjqnl+Z+I= Received: by 10.54.52.10 with SMTP id z10mr225069wrz; Wed, 28 Sep 2005 16:58:26 -0700 (PDT) Received: by 10.54.76.6 with HTTP; Wed, 28 Sep 2005 16:58:26 -0700 (PDT) Message-ID: <4e89b426050928165841e4a157@mail.gmail.com> Date: Wed, 28 Sep 2005 19:58:26 -0400 Reply-To: Wez Furlong To: Andi Gutmans Cc: Rasmus Lerdorf , internals@lists.php.net In-Reply-To: <6.2.3.4.2.20050928155517.04710860@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <433ABE48.6050607@lerdorf.com> <6.2.3.4.2.20050928155517.04710860@localhost> Subject: Re: [PHP-DEV] timezones & date() breakage From: kingwez@gmail.com (Wez Furlong) I agree; date() in 5.1 should default to the older "broken" code for BC and have a toggle for the new stuff. We could also issue a deprecation notice to warn people about a future move to the new code in PHP 6. This way we get the "best" of both worlds; BC is preserved for the masses of existing code and we get more QA on the new implementation ready for going production with the new code in PHP 6. --Wez. On 9/28/05, Andi Gutmans wrote: > 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 brok= e > > 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/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >