On 26 May 2013 07:44, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > > > I did not do a very good job explaining what I meant. I meant to say > > that requiring the timezone to be set prevents you from running > > without an ini file without any warnings. This is a big annoyance. > > If you insist on using the tool in a wrong way, you will be annoyed as > the tool would not work in a way you want it to work. The right way is > to set up the ini file. It takes about 2 seconds.
Not in direct response to the above point, but more of a comment on this thread, and the various reappearances of this thread. As I understand things, some of the issues with asking the OS for the timezone are: 1 - The OS may not present a timezone in a way that PHP can easily access in a consistent way (i.e. too many flavours, mechanisms, etc.). 2 - The machine's local time and/or timezone may not be set correctly anyway. A point come to mind, in addition to all of this (and I'm not an expert, but this may be important) ... As more and more site/services are being hosted in the cloud, allowing requests to be handled locally geographically, in different timezones, does it make ANY sense in setting a timezone at all other than UTC? >From what I can see, a server (which may not be under our control) COULD have pretty much any time and/or timezone on it. So even if we DO set a timezone in PHP, the time could still be out and that really isn't a good thing. If setting the timezone is so critical that a warning MUST be given when it is not set and that by ignoring the warning (either because of a lazy dev or a dev who cannot see the warning due to shared setup or something else) the scripts running that rely on accurate datetimezone, why not make this a fatal error. Yes. I know you've all jumped off your chairs to complain, but either PHP MUST have this setting appropriately, or it can live without it. The grey area of "PHP can run, but your results, well, meh!" does not fit well. If all it takes is 2s to set the INI file, why bother running without the setting. Is there any process that could be run that would do the following ... 1 - Determine the machines current date/time. 2 - Determine the machines current timezone (or lack of ability to return that information). 3 - Verify the local time with a known/accurate/maintained time server. 4 - From all of this, make an accurate decision or best guess as to what the timezone should be. 5 - Set an entry in the php.ini file appropriate for the guessed_timezone. So, the warning COULD be given, but allow a dev to run a PHP Team sourced process to determine where in the world the server is (I have access to servers all over Europe. I don't know the timezones that they are all in initially and had to work to confirm that the machine date/time/timezone was accurate. It would seem that a script could do this better, consistently, etc.). Just an idea on trying to solve this. If it could be automated, essentially whatever manual steps a dev would take to accurately set the timezone on an unknown server, then this process would certainly seem to be useful. But only because PHP gives a warning that the lack of the timezone is an issue. Regards, Richard. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
