LS>>Now the new code does cause problems for some (certainly not a majority of
LS>>people) and this needs to be taken into account. However if these people do

I wonder how do you know it's not a majority? Almost nobody is using 5.1 
in production now, but once it's out you are bound to get a rain of 
complaints once all date() function would start returning UTC and people 
would discover they need to find out "real name" for their timezone (which 
90% of them never knew or cared for since it's just worked once OS is 
installed) and put it into php.ini. And even once you figure that out in a 
couple of years, you still will have to deal with complaints like "DST 
settings in our country changed last year, our admin updated the system 
then but PHP still uses old ones, what do I do?" And I imagine most of the 
people don't write calendar applications, and even they do, they probably 
already work with date() as it is, so new date() would probably break them 
anyway.

LS>>growing pains boils down to forcing users/admins to set a single php.ini
LS>>setting and suddenly we do not have any code duplication. I think we have

That's not 'signle php.ini setting'. That's single php.ini setting on 
_each_ deployed machine, all different and with no way to do it 
automatically - only by manually looking up the manual (provided it exists 
- now it does not) for this specific function, writing it in php.ini and 
then hoping for the best. And as a bonus, this value has no 
working default, so there's no way you can just deploy 5.1 and run your 
apps - if they use date(), they are all instantly broken once you install 
5.1. Now try explaining to the user how breaking his working application 
is a feature.

LS>>Do you think this is not even a feasible vision for the future?

I think that 5.1 should break as little user code as possible, and I see 
absolutely no reason to break date() where it worked in 5.0. 

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to