Re: timezones & date() breakage

I completely agree here, and it was only because I was sure that it was only an implementation and not a functionality change that I agreed for it to be commited. We could do something like NIO in Java, and have newr APIs for this functionality, this way people who want to use the new APIs win (such as Derick) and old users don't have their applications broken. Andi At 05:59 AM 9/29/2005, Wez Furlong wrote:

Call it FUD if you like; I call it "sleeping easier at night". Like it or not, PHP is big enough now that these things have become critical points for larger businesses. To completely replace the default implementation of a core function with something new is quite a risk when it's not had enough QA. Take a look at Streams for example; things are still settling down there from their (embarrasingly buggy) 4.3 debut. You could argue that date/time support in PHP is more critical than streams, and so changing that worries me more. Whether we intend PHP 5.1 to be a bugfix release or not isn't really relevant; people will assume that PHP 5.1 is "PHP 5 with some things fixed and some new things added"... and isn't that really what our versioning scheme says it will be too? We're a big enough project to have a responsibility (http://netevil.org/node.php?nid=427) to our users. Progress isn't about breaking BC at every turn; take a look at the Solaris approach: innovate by creating new APIs and ensure stability by preserving existing APIs. This is a solid, reliable approach to software development, and improves the quality of sleep for us, people developing applications with PHP, people paying for PHP applications and for people using those "critical" applications (banking, travel, auctions). --Wez. On 9/29/05, Jani Taskinen <sniper@iki.fi> wrote:

     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 <andi@zend.com> 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 @ <http://pecl.php.net/wishlist.php/sniper> Disclaimer: Donating money may make me happier and friendlier for a limited period!

Zend/PHP Conference & Expo Power Your Business with PHP October 18-21, 2005 - San Francisco http://zend.kbconferences.com/