Re: timezones & date() breakage

Stanislav Malyshev wrote:

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

Please Stas .. I was talking about a long term vision. Why do you have to insist drawing up horror scenarios that are unrelated to my comments? While this may be an effective strategy in politics I find it unnecessary inside a technical discussion on open source software.

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.

Again I was not talking about PHP 5.1 .. I was talking about a long term vision. So that we can atleast agree on that and then come up with a migration plan (if needed) from there. As for your argument. Alot of settings in the php.ini are system specific and cannot be guessed. I agree we need to document this and with specific attention to those places where things overlap (which are exactly the cases that are likely to run into problems now).

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.

Thanks for not listening Stas. regards, Lukas