Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19273 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 78125 invoked by uid 1010); 28 Sep 2005 16:21:16 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 78110 invoked from network); 28 Sep 2005 16:21:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Sep 2005 16:21:16 -0000 X-Host-Fingerprint: 204.11.219.139 lerdorf.com Linux 2.4/2.6 Received: from ([204.11.219.139:53531] helo=colo.lerdorf.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 84/02-54476-B4EBA334 for ; Wed, 28 Sep 2005 12:01:16 -0400 Received: from [192.168.200.106] (c-24-6-5-134.hsd1.ca.comcast.net [24.6.5.134]) (authenticated bits=0) by colo.lerdorf.com (8.13.5/8.13.5/Debian-1) with ESMTP id j8SG1Cbf001856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Sep 2005 09:01:12 -0700 Message-ID: <433ABE48.6050607@lerdorf.com> Date: Wed, 28 Sep 2005 09:01:12 -0700 User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: internals@lists.php.net References: <43393A43.4070805@lsces.co.uk> <43397E48.7080107@lsces.co.uk> <43398CB6.9030808@lsces.co.uk> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] timezones & date() breakage From: rasmus@lerdorf.com (Rasmus Lerdorf) 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