This is probably a stupid question, but why isn't there a default setting? And why can't the missing default setting be set by the system date() data?
----- Original Message ----- From: "Stanislav Malyshev" <[EMAIL PROTECTED]> To: "Lukas Smith" <[EMAIL PROTECTED]> Cc: <internals@lists.php.net> Sent: Wednesday, September 28, 2005 1:33 PM Subject: Re: [PHP-DEV] timezones & date() breakage > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
