Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19286 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90429 invoked by uid 1010); 29 Sep 2005 07:32:13 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 90413 invoked from network); 29 Sep 2005 07:32:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Sep 2005 07:32:13 -0000 X-Host-Fingerprint: 194.73.73.210 c2bthomr02.btconnect.com FreeBSD 4.7-5.2 (or MacOS X 10.2-10.3) (2) Received: from ([194.73.73.210:26910] helo=c2bthomr02.btconnect.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 5C/FF-54476-C789B334 for ; Thu, 29 Sep 2005 03:32:13 -0400 Received: from [10.0.0.9] (host81-138-11-136.in-addr.btopenworld.com [81.138.11.136]) by c2bthomr02.btconnect.com (MOS 3.5.9-GR) with ESMTP id CJQ03877; Thu, 29 Sep 2005 08:31:49 +0100 (BST) Message-ID: <433B9874.4090704@lsces.co.uk> Date: Thu, 29 Sep 2005 08:32:04 +0100 Organization: L.S.Caine Electronic Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en, en-us MIME-Version: 1.0 To: internals@lists.php.net References: <433ABE48.6050607@lerdorf.com> <6.2.3.4.2.20050928155517.04710860@localhost> <4e89b426050928165841e4a157@mail.gmail.com> <6.2.3.4.2.20050928213727.0367b880@localhost> In-Reply-To: <6.2.3.4.2.20050928213727.0367b880@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] timezones & date() breakage From: lester@lsces.co.uk (Lester Caine) Andi Gutmans wrote: > I agree, and we should currently have both so that we can migrate users > to Derick's new code. Derick, I think you need to return the support for > the old functionality (it can probably be done quite easily by taking > the old code as-is). We should then have an INI option which selects > between the two (I hate INIs but I don't see much of a way around it). > To be realistic, considering the possible breakage in apps, I don't > believe 5.1 can be released in the current state. We should be able to run 5.1 on a 5.0 system and at worst get warnings - hidden potential differences are something to be avoided ;) Would it be possible to have dev snapshots of PHP6 on windows where *THIS* sort of thing can be played with in earnest and the migration notes worked out. ( Probably need those from both PHP4 and PHP5 :( ) I started playing with PHP5 well before it was finally released so never bothered with PHP4 in production. Having to try and maintain BC with PHP4 in OS projects is becoming a pain, and all these 'subtle changes' being applied to PHP5 and back ported to PHP4 are just adding unnecessary work. *PLEASE* can we have a *PROPER* freeze on some back porting and set a rule that once PHP6 is more accessible ( I NEED UNICODE ;) ) then nothing will be applied to PHP4 that requires any code changes and ideally PHP5 as well ? Hopefully the tidy UNICODE implementation in PHP6 will provide enough incentive for 4 and 5 to be sidelined? But we are probably going to need a 'code tidier' that identifies areas that need work in legacy code? -- Lester Caine ----------------------------- L.S.Caine Electronic Services Treasurer - Firebird Foundation Inc.