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.
Thanks,
Andi
At 04:58 PM 9/28/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 <[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
>
>
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
