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 <[EMAIL PROTECTED]> 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 > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
