Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19287 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 9898 invoked by uid 1010); 29 Sep 2005 08:44:52 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 9859 invoked from network); 29 Sep 2005 08:44:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Sep 2005 08:44:52 -0000 X-Host-Fingerprint: 195.197.172.115 gw01.mail.saunalahti.fi Linux 2.4/2.6 Received: from ([195.197.172.115:35905] helo=gw01.mail.saunalahti.fi) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 15/61-54476-FB3AB334 for ; Thu, 29 Sep 2005 04:20:15 -0400 Received: from nest.netphobia.fi (YZDCXXXI.dsl.saunalahti.fi [85.76.35.232]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 3E193F18E3; Thu, 29 Sep 2005 11:20:08 +0300 (EEST) Received: from nest.netphobia.fi (nest.netphobia.fi [127.0.0.1]) by nest.netphobia.fi (8.13.1/8.13.1) with ESMTP id j8T8K9Q4018327; Thu, 29 Sep 2005 11:20:09 +0300 Received: from localhost (jani@localhost) by nest.netphobia.fi (8.13.1/8.13.1/Submit) with ESMTP id j8T8K8I3018324; Thu, 29 Sep 2005 11:20:08 +0300 X-Authentication-Warning: nest.netphobia.fi: jani owned process doing -bs Date: Thu, 29 Sep 2005 11:20:08 +0300 (EEST) Reply-To: Jani Taskinen To: Wez Furlong cc: Andi Gutmans , Rasmus Lerdorf , internals@lists.php.net In-Reply-To: <4e89b426050928165841e4a157@mail.gmail.com> Message-ID: References: <433ABE48.6050607@lerdorf.com> <6.2.3.4.2.20050928155517.04710860@localhost> <4e89b426050928165841e4a157@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [PHP-DEV] timezones & date() breakage From: sniper@iki.fi (Jani Taskinen) The "masses" don't have to update. The old broken date() is still in PHP 4.4.0 and PHP 5.0.x. Please stop the BC fud, this is not about a bugfix release but something a bit bigger thing. One other solution: we can always change PHP_5_1 to PHP_6 and do all other nice "BC" breaks too while we're at it.. And start calling HEAD PHP 7.0 =) --Jani On Wed, 28 Sep 2005, Wez Furlong wrote: > > 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 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/ >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > -- Donate @ Disclaimer: Donating money may make me happier and friendlier for a limited period!