# date.timezone E_WARNING -- Really necessary? What's the rationale? - Thread: https://externals.io/message/67458 - Original archive: https://news-web.php.net/php.internals/67458 - Started by Daniel Lowrey on 2013-05-23T18:40:02+00:00 - Messages: 65 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/67458.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #67458 — Daniel Lowrey — 2013-05-23T18:40:02+00:00 URL: https://externals.io/message/67458#67458 I'm probably not the typical PHP user; I spend 99% of my PHP time using the CLI (and not web SAPIs). This means that I frequently run PHP without an .ini file. As a result, when I use any of the date/time functionality I invariably end up with this awesomeness: > Warning: `date()`: It is not safe to rely on the system's timezone settings blah blah blah. Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but should that really be necessary? It seems to me this warning caters to the very lowest common denominator among PHP devs who can't be bothered to understand how PHP handles timezones. The warning also seems to assume that people only use PHP as a web framework and not as an actual programming language (otherwise I wouldn't have to explain to the CLI which timezone I want to use). I don't need php.ini ... I want to use PHP to *program*. If it's going to default to UTC anyway should there really be an E_WARNING? Can't PHP just quietly use UTC? The "U" in UTC *does* stand for "Universal," after all. It's a sensible default and as such shouldn't merit a warning. Besides, if someone doesn't understand what's happening and gets unexpected date/time results the first thing they're going to do (I hope) is hit their favorite search engine for "set PHP timezone." Perhaps I'm the only person to experience ongoing annoyance at the hands of this protective "feature?" Is there a substantive reason why this warning exists other than the error message's suggestion that "you most likely misspelled the timezone identifier?" I understand that one of PHP's most attractive features is ease-of-use for programming novices but you can only go so far in preventing people who don't know what they're doing from shooting themselves in the foot. I'm not sure if it's possible but perhaps a compromise might be to disable this warning in the CLI, at least? --- ## #67459 — Nikita Popov — 2013-05-23T18:48:53+00:00 URL: https://externals.io/message/67458#67459 · In reply to: #67458 > I'm probably not the typical PHP user; I spend 99% of my PHP time > using the CLI (and not web SAPIs). > This means that I frequently run PHP without an .ini file. As a > result, when I use any of the date/time > functionality I invariably end up with this awesomeness: > > > […] > settings blah blah blah. > > Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but > should that really be necessary? > It seems to me this warning caters to the very lowest common > denominator among PHP devs who can't > be bothered to understand how PHP handles timezones. The warning also > seems to assume that people only > use PHP as a web framework and not as an actual programming language > (otherwise I wouldn't have to > explain to the CLI which timezone I want to use). I don't need php.ini > ... I want to use PHP to *program*. > > If it's going to default to UTC anyway should there really be an > E_WARNING? Can't PHP just quietly use UTC? > The "U" in UTC *does* stand for "Universal," after all. It's a > sensible default and as such shouldn't > merit a warning. Besides, if someone doesn't understand what's > happening and gets unexpected date/time > results the first thing they're going to do (I hope) is hit their > favorite search engine for "set PHP timezone." > > Perhaps I'm the only person to experience ongoing annoyance at the > hands of this protective > "feature?" Is there a substantive reason why this warning exists other > than the error message's > suggestion that "you most likely misspelled the timezone identifier?" > I understand that one of PHP's > most attractive features is ease-of-use for programming novices but > you can only go so far in > preventing people who don't know what they're doing from shooting > themselves in the foot. > > I'm not sure if it's possible but perhaps a compromise might be to > disable this warning in the CLI, at least? Fully agreed. The warning is very annoying when using CLI. And even when not using CLI: The timezone is usually only relevant in production. I don't care if times are off a few hours when developing stuff. Nikita --- ## #67460 — Stas Malyshev — 2013-05-23T20:10:28+00:00 URL: https://externals.io/message/67458#67460 · In reply to: #67458 Hi! > I'm probably not the typical PHP user; I spend 99% of my PHP time > using the CLI (and not web SAPIs). > This means that I frequently run PHP without an .ini file. As a I'm not sure how this follows - CLI is capable of using ini file just like the rest of SAPIs. Why not create it? > The "U" in UTC *does* stand for "Universal," after all. It's a > sensible default and as such shouldn't I don't think it's a sensible default - people don't actually use UTC when considering dates. A minority of people can use timezone that coincides with UTC, but not very many use actual UTC. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #67472 — Daniel Lowrey — 2013-05-24T00:26:24+00:00 URL: https://externals.io/message/67458#67472 · In reply to: #67460 I guess my point is that I don't believe default settings should trigger errors. If it's a default setting, it's a default setting. Document it and move on. It's then the user's responsibility to define that value correctly if he/she wants something other than the default. I don't personally see much difference between triggering `E_WARNING` for date.timezone and -- for example -- open_basedir. There's no error to tell me that my script can access the entire filesystem without an open_basedir setting and that this could be a potential security risk. There's no `E_WARNING` to say that the default memory_limit value is 128M and that if I want to use more than that I need to define it in php.ini. Where does it stop? It seems like an eminently unsustainable practice to trigger errors for every possible oops in your .ini file. For me, the date.timezone warning has no positive benefit and provides real annoyance every single day. Is that the case for others? I can't say, that's why I'm complaining on the internals list :) > Hi! > > > […] > > I'm not sure how this follows - CLI is capable of using ini file just > like the rest of SAPIs. Why not create it? > > > […] > > I don't think it's a sensible default - people don't actually use UTC > when considering dates. A minority of people can use timezone that > coincides with UTC, but not very many use actual UTC. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #67474 — Derick Rethans — 2013-05-24T00:40:46+00:00 URL: https://externals.io/message/67458#67474 · In reply to: #67472 > I guess my point is that I don't believe default settings should > trigger errors. If it's a default setting, it's a default setting. No - you, as an admin, are required to make an informed decision on what you want your timezone to be. There have been way too many bug reports where people had no clue, so now we throw a warning. cheers, Derick --- ## #67478 — leafnode@gmail.com — 2013-05-24T05:48:27+00:00 URL: https://externals.io/message/67458#67478 · In reply to: #67460 > > […] > I don't think it's a sensible default - people don't actually use UTC > when considering dates. A minority of people can use timezone that > coincides with UTC, but not very many use actual UTC. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be "from operating system", with possibility to override it in .ini. --Leszek --- ## #67480 — Levi Morrison — 2013-05-24T07:11:22+00:00 URL: https://externals.io/message/67458#67480 · In reply to: #67478 > > […] > > I was wondering - why not get time zone info from operating system? It's > should be quite easy on both *nixes and Windows. That way default value > would be "from operating system", with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. --- ## #67482 — Kris Craig — 2013-05-24T08:16:33+00:00 URL: https://externals.io/message/67458#67482 · In reply to: #67480 On Fri, May 24, 2013 at 12:11 AM, Levi Morrison wrote: > > […] > .ini. > > I believe this may have been the behavior at some point; at least > date_default_timezone_get change in PHP 5.4 to no longer includes info > from the OS. > > -- > > > > Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. Thoughts? --Kris --- ## #67483 — Kris Craig — 2013-05-24T08:20:25+00:00 URL: https://externals.io/message/67458#67483 · In reply to: #67482 > > > On Fri, May 24, 2013 at 12:11 AM, Levi Morrison wrote: > > > […] > Couldn't we take a page from MySQL's book and have a setup script that > prompts the admin for this (much like theirs prompts for a root password). > A reminder to run it could be added as a nag at the end of the install; > or, perhaps even have it give you these setup prompts at the end of make > install. This way, any environment-specific settings we think should be > there that don't have obvious defaults, like date.timezone, could be added > as prompts in the setup script. This would enable even inexperienced > admins to add these settings without cluttering-up the bugs tracker. > > Thoughts? > > --Kris > > Another possible idea would be to make it so that you can specify the date.timezone in configure. This would cause make install to automatically set it in php.ini. That might be useful for folks like Daniel who don't like having to do that extra step of manually editing php.ini to avoid throwing warning errors. --Kris --- ## #67484 — johannes@schlueters.de — 2013-05-24T08:34:02+00:00 URL: https://externals.io/message/67458#67484 · In reply to: #67482 > Couldn't we take a page from MySQL's book and have a setup script that > prompts the admin for this (much like theirs prompts for a root password). > A reminder to run it could be added as a nag at the end of the install; > or, perhaps even have it give you these setup prompts at the end of make > install. This way, any environment-specific settings we think should be > there that don't have obvious defaults, like date.timezone, could be added > as prompts in the setup script. This would enable even inexperienced > admins to add these settings without cluttering-up the bugs tracker. An estimate of >90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. johannes --- ## #67486 — leafnode@gmail.com — 2013-05-24T08:45:30+00:00 URL: https://externals.io/message/67458#67486 · In reply to: #67484 > > > […] > An estimate of >90% of our users who are actually installing PHP > themselves are using distribution packages of PHP and not our sources. > They expect `[yum|apt-get|...] install php` to be the whole installation > process. > Yet it's not uncommon for yum/apt-get/whatever to ask for input (like mentioned MySQL asking for root password). --Leszek --- ## #67499 — Derick Rethans — 2013-05-24T16:45:35+00:00 URL: https://externals.io/message/67458#67499 · In reply to: #67478 > > > […] > > I was wondering - why not get time zone info from operating system? It's > should be quite easy on both *nixes and Windows. That way default value would > be "from operating system", with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. cheers, Derick --- ## #67500 — Derick Rethans — 2013-05-24T16:53:20+00:00 URL: https://externals.io/message/67458#67500 · In reply to: #67486 > > > […] > > Yet it's not uncommon for yum/apt-get/whatever to ask for input (like > mentioned MySQL asking for root password). I'm pretty sure apt can read the configuration from their "tzdata" package to add the correct setting to php.ini: a=`debconf-show tzdata | grep Areas | sed 's/.*\s//'`; b=`debconf-show tzdata | grep Zones/$a | sed 's/.*\s//'`; echo "$a/$b" However, that is something for distributions to do as each distribution's mechanism is different. cheers, Derick --- ## #67501 — Patrick Schaaf — 2013-05-24T18:10:48+00:00 URL: https://externals.io/message/67458#67501 · In reply to: #67499 Am 24.05.2013 18:45 schrieb "Derick Rethans" : > > > > > […] would > > […] > > You can't, as the OS doesn't give you the timezone identifier in a > portable way. Couldn´t the default, in the absense of an .ini setting, be to use `localtime()`, i.e. whatever libc does, with the timezone _identifier_ being some string like "OS", "System", or "Localtime" - and we could then also use that identifier in .ini or ini_set to precisely say "use the same timezone as all the other libc using programs on this system". best regards Patrick --- ## #67502 — Derick Rethans — 2013-05-24T18:23:25+00:00 URL: https://externals.io/message/67458#67502 · In reply to: #67501 > Am 24.05.2013 18:45 schrieb "Derick Rethans" : > > […] > > Couldn´t the default, in the absense of an .ini setting, be to use > `localtime()`, i.e. whatever libc does, with the timezone _identifier_ > being some string like "OS", "System", or "Localtime" - and we could > then also use that identifier in .ini or ini_set to precisely say "use > the same timezone as all the other libc using programs on this > system". Absolutely not, as you can then never convert between that and another zone. This nonsense is what Redhat patches into it as well and it is a BAD idea. You'd have no idea which DST rules are cheers, Derick --- ## #67503 — Ralph Schindler — 2013-05-24T18:52:11+00:00 URL: https://externals.io/message/67458#67503 · In reply to: #67460 While UTC is not *ideal*, I am failing to see why its not a reasonable default. After all, according to http://us3.php.net/manual/en/function.date-default-timezone-get.php "If none of the above succeed, `date_default_timezone_get()` will return a default timezone of UTC." If people care about dealing with time's in a non-UTC way, it seems to me they they would either A) ensure their server is set to an appropriate timezone (by setting it or bugging their system administrator) or B) ensuring their app calls `date_default_timezone_set()` in a bootstrap/initialization script (globally) or C) set the timezone in an application context specific way through DateTime::setTimezone(). As far as I can tell, with all standard distribution extensions, there is no other extension that will toss a warning with the default configuration... thus making this the outlier. -ralph > Hi! > > > […] > > I'm not sure how this follows - CLI is capable of using ini file just > like the rest of SAPIs. Why not create it? > > > […] > > I don't think it's a sensible default - people don't actually use UTC > when considering dates. A minority of people can use timezone that > coincides with UTC, but not very many use actual UTC. --- ## #67504 — Levi Morrison — 2013-05-24T19:18:54+00:00 URL: https://externals.io/message/67458#67504 · In reply to: #67503 > "If none of the above succeed, `date_default_timezone_get()` will return a > default timezone of UTC." It will still raise a warning, by the way. This is horrible behavior; I recommend the following: date_default_timezone_set(ini_get('date.timezone') ?: 'UTC'); This is basically what date_default_timezone_get does as of PHP 5.4 except there is no warning. --- ## #67506 — Nikita Popov — 2013-05-24T21:35:52+00:00 URL: https://externals.io/message/67458#67506 · In reply to: #67474 > > > > […] > > No - you, as an admin, are required to make an informed decision on what > you want your timezone to be. There have been way too many bug reports > where people had no clue, so now we throw a warning. > Sorry, but I fail to see why date.timezone needs special handling. What makes the date.timezone setting so important, that it is the only one which value you are required to set? There are settings that are arguably a lot more important than this, but which do not throw such warnings. E.g., why isn't there a warning for cases where error_reporting is not explicitly specified? I can't count the number of StackOverflow questions caused by bad error_reporting settings and I'm very sure this number surpasses complains about timezones by several orders of magnitude. Yet - of course! - we do no such thing, for it is senseless. After all, there *is* a reason why we have defaults for ini settings. People should only be required to changed them when necessary. Date.timezone should be no exception to this. Nikita --- ## #67510 — Tim Starling — 2013-05-25T10:31:24+00:00 URL: https://externals.io/message/67458#67510 · In reply to: #67458 > If it's going to default to UTC anyway should there really be an > E_WARNING? Can't PHP just quietly use UTC? The "U" in UTC *does* > stand for "Universal," after all. It's a sensible default and as > such shouldn't merit a warning. Actually, the sensible default is what guess_timezone() does already, except without the warnings. You can get that behaviour with e.g. date_default_timezone_set( @date_default_timezone_get() ); at the top of your program. That's what MediaWiki does (except with by modifying error_reporting instead of using @). We stole the idea from another web app. It's more convenient than duplicating the functionality of guess_timezone() in the application. It's Derick's prerogative to annoy all users half to death with warnings, as his way of indicating his distaste for the state of OS support for querying of system timezone. That's the reward we give him for writing lots of date/time code. -- Tim Starling --- ## #67512 — Pierre Joye — 2013-05-25T12:09:53+00:00 URL: https://externals.io/message/67458#67512 · In reply to: #67510 . > > It's Derick's prerogative to annoy all users half to death with > warnings, as his way of indicating his distaste for the state of OS > support for querying of system timezone. It is actually only about getting safe, cross platform/OS (even between Linux versions) for the TZ database. It has nothing to do with taste or similar subjective opinion. For the record, the behavior requested in this thread is what we had in earlier versions, all we got was plenty of bugs reports about wrong TZ detections. I think it is not too much asking to set it in php.ini or in your application. --- ## #67513 — Pierre Schmitz — 2013-05-25T12:30:28+00:00 URL: https://externals.io/message/67458#67513 · In reply to: #67512 Am 25.05.2013 14:09, schrieb Pierre Joye: > > . > > […] > > It is actually only about getting safe, cross platform/OS (even between > Linux versions) for the TZ database. It has nothing to do with taste or > similar subjective opinion. > > For the record, the behavior requested in this thread is what we had in > earlier versions, all we got was plenty of bugs reports about wrong TZ > detections. > > I think it is not too much asking to set it in php.ini or in your > application. Wouldn't it be possible to have it default to the system's timezone if available? Most software seems to be able to use the correct timezone. From a user's pov it is strange that PHP is pretty much the only service which has to have it's own timezone configuration. Or maybe one could make it a compile time option and distros that for some reason have no usable system time zone can disable this feature. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com --- ## #67514 — Levi Morrison — 2013-05-25T15:03:01+00:00 URL: https://externals.io/message/67458#67514 · In reply to: #67512 > For the record, the behavior requested in this thread is what we had in > earlier versions, all we got was plenty of bugs reports about wrong TZ > detections. This issue is less about date.timezone than being able to run without an ini file. --- ## #67515 — Paul Reinheimer — 2013-05-25T15:03:11+00:00 URL: https://externals.io/message/67458#67515 · In reply to: #67513 Hi List, > Wouldn't it be possible to have it default to the system's timezone if > available? Most software seems to be able to use the correct timezone. > From a user's pov it is strange that PHP is pretty much the only service > which has to have it's own timezone configuration. > > I appreciate the current state of things. There's only one thing worse than having an operation return the wrong answer, and that's having it return the wrong answer silently. The latter can happen with the wrong TZ setting. I've got a myriad of different systems to deal with, some distro-based installs of PHP separating out php.ini for the CLI, and for Apache. Other installs using the same file like I expect. I make mistakes. I'm currently maintaining ~100 servers from a slew of different providers around the world. The clock is hard enough to trust, let alone what the system's TZ setting is. The #1 answer from providers when we complain that the clock is 2 hours off is to just change the timezone. When I get the blast of warnings, I'm shaken from complacency to invest one minute to find the right file, add the setting, and forget about it once more. paul --- ## #67516 — Tim Starling — 2013-05-25T15:05:04+00:00 URL: https://externals.io/message/67458#67516 · In reply to: #67512 > > It is actually only about getting safe, cross platform/OS (even > between Linux versions) for the TZ database. It has nothing to do > with taste or similar subjective opinion. > > For the record, the behavior requested in this thread is what we had > in earlier versions, all we got was plenty of bugs reports about > wrong TZ detections. > I had missed the removal of the TZ detection code from guess_timezone() in 5.4. So @date_default_timezone_get() is somewhat less useful than it used to be, as a function for detecting system settings. > I think it is not too much asking to set it in php.ini or in your > application. > At least for MediaWiki, it's certainly more important to avoid warnings than it is to have the right local timezone. UTC is used in any case where consistency is important. Based on other posts to this list, I don't think we're alone in this. -- Tim Starling --- ## #67517 — Levi Morrison — 2013-05-25T15:06:35+00:00 URL: https://externals.io/message/67458#67517 · In reply to: #67514 > > […] > > This issue is less about date.timezone than being able to run without > an ini file. 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. --- Next page: https://externals.io/message/67458.md?page=2