On Wed, 28 Sep 2005 09:01:12 -0700 [EMAIL PROTECTED] (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. Except that one should listen to valid concerns and not commit anything to a feature freezed branche. Sorry to say it again and again, but I'm really pissed off by this attitude. > 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. I prefer some ears vacuum cleaner. > 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. The problem is to prevent the points of failures, to provide a BC fix for each of them. It could be possible if we have a way to tests and compare the 4.x - 5.0.x behaviors with Derick implementations, but we have nothing but a huge amount of suppositions. As I said, I doubt we can delay again 5.1.0 for some more weeks. Unless we drop all the Derick's changes and restore the previous codes, I doubt we have enough time to find a valid solution or implement any fancy tags. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
