# [RFC] Remove the date.timezone warning - Thread: https://externals.io/message/81184 - Original archive: https://news-web.php.net/php.internals/81184 - Started by Bob Weinand on 2015-01-27T00:34:35+00:00 - Messages: 25 - RFC: Remove the date.timezone warning (Implemented (PHP 7.0)) — https://externals.io/rfc/date.timezone_warning_removal.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #81184 — Bob Weinand — 2015-01-27T00:34:35+00:00 URL: https://externals.io/message/81184#81184 Hey, I'd like to request removal of the date.timezone warning. Here is the RFC: https://wiki.php.net/rfc/date.timezone_warning_removal Bob --- ## #81189 — Yasuo Ohgaki — 2015-01-27T01:16:10+00:00 URL: https://externals.io/message/81184#81189 · In reply to: #81184 HI Bob, > > I'd like to request removal of the date.timezone warning. > > Here is the RFC: > https://wiki.php.net/rfc/date.timezone_warning_removal Nice RFC. I would like to remove the warning, too. Setting it to UTC without warning sounds reasonable to me. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #81196 — Kalle Sommer Nielsen — 2015-01-27T03:56:58+00:00 URL: https://externals.io/message/81184#81196 · In reply to: #81184 Hi 2015-01-27 1:34 GMT+01:00 Bob Weinand : > Hey, > > I'd like to request removal of the date.timezone warning. > > Here is the RFC: > https://wiki.php.net/rfc/date.timezone_warning_removal > > Bob I think the warning is fair as it is, if it is annoying for small use cases like on the CLI then simply: php -d date.timezone=UTC -r "echo date('H:i:s');" or the dirty way by using the silent operator. It used to be a notice prior 5.3 I think or something. While I do agree that most applications should be using UTC, which should be set by default we sometimes need to tell userland the hard way how things work, and/or what they should care about, like the E_WARNING, E_CORE_ERROR, `E_DEPRECATED` for old php.ini settings. -1 for removing it from my side. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #81198 — Yasuo Ohgaki — 2015-01-27T04:24:51+00:00 URL: https://externals.io/message/81184#81198 · In reply to: #81196 Hi Kalle and all, On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen wrote: > I think the warning is fair as it is, if it is annoying for small use > cases like on the CLI then simply: php -d date.timezone=UTC -r "echo > date('H:i:s');" or the dirty way by using the silent operator. It used > to be a notice prior 5.3 I think or something. > > While I do agree that most applications should be using UTC, which > should be set by default we sometimes need to tell userland the hard > way how things work, and/or what they should care about, like the > E_WARNING, E_CORE_ERROR, `E_DEPRECATED` for old php.ini settings. > > -1 for removing it from my side. > I can understand your argument. Perhaps, we may reconsider to introduce E_DEBUG/E_USER_DEBUG for these purposes. There are many functions, e.g. file related, that I feel `E_WARNING` is excessive. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #81199 — Pierre Joye — 2015-01-27T04:32:51+00:00 URL: https://externals.io/message/81184#81199 · In reply to: #81198 > > Hi Kalle and all, > > On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen > wrote: > > > […] > > I can understand your argument. > Perhaps, we may reconsider to introduce E_DEBUG/E_USER_DEBUG for these > purposes. > There are many functions, e.g. file related, that I feel `E_WARNING` is > excessive. I do not have a strong opinion on that. So keep it or make it UTC default but please do not add yet another warning/notice/whatever. Also, setting a timezone is not about Dev or other fancy tasks, it is about making datetime processing right. If anything I would enforce the default at configure/build time. So it at least gets the correct one from a host point of view. Cheers, Pierre --- ## #81202 — Matteo Beccati — 2015-01-27T06:40:51+00:00 URL: https://externals.io/message/81184#81202 · In reply to: #81184 > Hey, > > I'd like to request removal of the date.timezone warning. > > Here is the RFC: > https://wiki.php.net/rfc/date.timezone_warning_removal The warning is certainly annoying, but making it default to UTC or a wrong timezone because the right one can't be guessed is a major WTF. Ideally the initial setup of php.ini could be handled by the distro package system, if it's not already? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #81203 — Sebastian Bergmann — 2015-01-27T07:11:15+00:00 URL: https://externals.io/message/81184#81203 · In reply to: #81202 Am 27.01.2015 um 07:40 schrieb Matteo Beccati: > The warning is certainly annoying, but making it default to UTC or a wrong > timezone because the right one can't be guessed is a major WTF. Couldn't agree more; -1 for removing the warning. --- ## #81209 — Derick Rethans — 2015-01-27T09:33:07+00:00 URL: https://externals.io/message/81184#81209 · In reply to: #81184 > I'd like to request removal of the date.timezone warning. > > Here is the RFC: > https://wiki.php.net/rfc/date.timezone_warning_removal Absolutely not. cheers, Derick --- ## #81210 — Derick Rethans — 2015-01-27T09:36:46+00:00 URL: https://externals.io/message/81184#81210 · In reply to: #81199 > > > […] > > I do not have a strong opinion on that. So keep it or make it UTC > default but please do not add yet another warning/notice/whatever. > > Also, setting a timezone is not about Dev or other fancy tasks, it is > about making datetime processing right. > > If anything I would enforce the default at configure/build time. So it > at least gets the correct one from a host point of view. That would be nice, but it's unfortuntately not really possible. You can't find out what timezone the OS is using in a portable way. Not even among different linux distributions, let alone having Windows in the mix. We tried this before, and because it caused so many issues, the current warning was added (instead of trying to guess a timezone). cheers, Derick --- ## #81211 — Derick Rethans — 2015-01-27T09:38:04+00:00 URL: https://externals.io/message/81184#81211 · In reply to: #81202 > > > […] > > The warning is certainly annoying, but making it default to UTC or a > wrong timezone because the right one can't be guessed is a major WTF. Exactly. > Ideally the initial setup of php.ini could be handled by the distro > package system, if it's not already? None of the distros do it well enough. Some even invent stupid stuff like "System.Localtime" as their timezone identifier, while they really should just figure out what timezone is configured for the system, and put that in a datetime.ini setting in their php.d/ dir or whatever they use. cheers, Derick --- ## #81212 — Lester Caine — 2015-01-27T09:41:01+00:00 URL: https://externals.io/message/81184#81212 · In reply to: #81203 > > […] > Couldn't agree more; -1 for removing the warning. Ditto The warning is a pain but only where the timezone setting is not ACTUALLY being handled by some other process. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #81220 — Yasuo Ohgaki — 2015-01-27T10:24:06+00:00 URL: https://externals.io/message/81184#81220 · In reply to: #81212 Hi all, While I can understand the reason behind opposition, but current web is not bounded to local country. Most applications today logs time using UTC and time stamp is converted whatever local time as needed, isn't it? Of course, it depends on application though. Having UTC as the default makes sense to me. Besides time management best practice, users have learned enough, haven't them? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #81221 — Florian Anderiasch — 2015-01-27T10:37:35+00:00 URL: https://externals.io/message/81184#81221 · In reply to: #81202 > > > […] > > The warning is certainly annoying, but making it default to UTC or a > wrong timezone because the right one can't be guessed is a major WTF. I don't see how this would be a *major* WTF. Maybe a minor one as PHP didn't have to have a default one, so maybe an oddity. I'd argue that it's about setting a good example, UTC is the only sane default for server software unless you know what you're doing. We're always arguing about removing options from php.ini and while it isn't about *removal* here I don't see why there can't be a sane default. I just reread the RFC, so I'm -1 on next minor version, but +1 on PHP 7. ~Florian --- ## #81224 — Nikita Popov — 2015-01-27T10:48:53+00:00 URL: https://externals.io/message/81184#81224 · In reply to: #81202 > > > > […] > > The warning is certainly annoying, but making it default to UTC or a wrong > timezone because the right one can't be guessed is a major WTF. > > Ideally the initial setup of php.ini could be handled by the distro > package system, if it's not already? > > > Cheers Isn't UTC the only "right" default timezone there is for a server? Everything else being there to simplify implementation of websites which anticipate a geographically narrow target audience? Anyway, I absolutely don't get why out of all the hundreds of ini settings that we have, some of them vastly more important than setting a timezone (like display_errors or error_reporting - newbies trip over these much more often), the only one we actually require you to specify is date.timezone. That seems very disproportional. Nikita --- ## #81225 — Lester Caine — 2015-01-27T10:54:34+00:00 URL: https://externals.io/message/81184#81225 · In reply to: #81220 > While I can understand the reason behind opposition, but current web is not > bounded to local country. Most applications today logs time using UTC and > time stamp is converted whatever local time as needed, isn't it? Of course, > it depends on application though. Having UTC as the default makes sense > to me. > > Besides time management best practice, users have learned enough, > haven't them? Best practice when working cross timezones is to store all information as UTC and display using a clients local timezone. It all falls apart when one starts trying to put into practice. Most 'local' PHP installations will be run on machines with their real time clock set to local time. If they are accessed by remote clients, the browsers tz offset will be used in the absence of a real DST correct timezone. Many sites will be using 'seconds' as the time base without knowing if leap seconds are included or not and wondering why things are not quite right. So basically defaulting the majority of PHP installs to UTC is simply wrong, if only because we can't even agree on how UTC is calculated. It was hoped that the new tzdist working group might bring a bit of sanity, but it seems providing a standard to work to is not what any of these working groups is chartered to provide - just rules so that everybody can carry on doing their own thing :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #81230 — Derick Rethans — 2015-01-27T11:17:00+00:00 URL: https://externals.io/message/81184#81230 · In reply to: #81220 > While I can understand the reason behind opposition, but current web > is not bounded to local country. Most applications today logs time > using UTC and time stamp is converted whatever local time as needed, > isn't it? Of course, it depends on application though. Having UTC as > the default makes sense to me. But not to me. Here in the UK, it would be right during winter, but then suddenly in summer my time would be wrong! It would be quite a WTF factor, and it's best fixed by having people actively make a choice on which timezone they want to use. > Besides time management best practice, users have learned enough, > haven't them? You'd be surprised how many people get timezones and time management wrong. I've given several talks about this and any time many attendees are surprised by the complexity. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #81231 — Derick Rethans — 2015-01-27T11:19:35+00:00 URL: https://externals.io/message/81184#81231 · In reply to: #81221 > > > […] > > I don't see how this would be a *major* WTF. Maybe a minor one as PHP > didn't have to have a default one, so maybe an oddity. > > I'd argue that it's about setting a good example, UTC is the only sane > default for server software unless you know what you're doing. They only sane default is no default, so that users have to make a choice as what to set it too. That gives the least amount of surprise. > We're always arguing about removing options from php.ini I think the argument is often about *not adding options*. Which is different from removing options. cheers, Derick --- ## #81232 — Derick Rethans — 2015-01-27T11:22:35+00:00 URL: https://externals.io/message/81184#81232 · In reply to: #81224 > > > > […] > > Isn't UTC the only "right" default timezone there is for a server? This is not a server setting, this is a PHP application level setting. And there, UTC is not the "right" default choice. > Everything else being there to simplify implementation of websites > which anticipate a geographically narrow target audience? > > Anyway, I absolutely don't get why out of all the hundreds of ini > settings that we have, some of them vastly more important than setting > a timezone (like display_errors or error_reporting - newbies trip over > these much more often), the only one we actually require you to > specify is date.timezone. That seems very disproportional. But easily solved by distributions. Debian could easily stick the following in a post-install hook to fix it: echo -n 'date.timezone=' > /etc/php/config.d/date.ini cat /etc/timezone >> /etc/php/config.d/date.ini cheers, Derick --- ## #81233 — Nikita Popov — 2015-01-27T11:28:17+00:00 URL: https://externals.io/message/81184#81233 · In reply to: #81232 > > […] > > But easily solved by distributions. Debian could easily stick the > following in a post-install hook to fix it: > > echo -n 'date.timezone=' > /etc/php/config.d/date.ini > cat /etc/timezone >> /etc/php/config.d/date.ini > So let the distros solve it ... and allow PHP to still be usable without an ini file. Nikita --- ## #81234 — Matteo Beccati — 2015-01-27T11:49:48+00:00 URL: https://externals.io/message/81184#81234 · In reply to: #81233 > So let the distros solve it ... and allow PHP to still be usable without an > ini file. So, I install php from sources and (simulating the RFC): # php -d date.timezone='' -r 'var_dump(@date("Y-m-d H:i:s"));' string(19) "2015-01-27 11:39:43" # date Tue Jan 27 12:39:45 CET 2015 how many people would think "WTF"? how many "oh right, PHP defaults to UTC unless I change my php.ini"? how many "my mistake! of course my laptop should use UTC!"? Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #81241 — Bob Weinand — 2015-01-27T14:12:57+00:00 URL: https://externals.io/message/81184#81241 · In reply to: #81234 > Am 27.01.2015 um 12:49 schrieb Matteo Beccati : > > > > […] > > So, I install php from sources and (simulating the RFC): > > # php -d date.timezone='' -r 'var_dump(@date("Y-m-d H:i:s"));' > string(19) "2015-01-27 11:39:43" > # date > Tue Jan 27 12:39:45 CET 2015 > > how many people would think "WTF"? > > how many "oh right, PHP defaults to UTC unless I change my php.ini"? > > how many "my mistake! of course my laptop should use UTC!"? > > > Cheers > -- > Matteo Beccati > > Development & Consulting - http://www.beccati.com/ If you use the distros default, it often is UTC too. Then we have this same issue, just without warning. This warning often doesn't help at all, because it just doesn't appear at all. If you use no ini, you probably are much more aware of that already... Bob --- ## #81244 — Matteo Beccati — 2015-01-27T15:27:37+00:00 URL: https://externals.io/message/81184#81244 · In reply to: #81241 > If you use the distros default, it often is UTC too. Then we have > this same issue, just without warning. This warning often doesn't > help at all, because it just doesn't appear at all. Well, if the distro sets display_errors = Off but doesn't also set a proper timezone, I would dare to say it's a bug in their packages. Vanilla PHP doesn't do that; it does if you blindly use php.ini-production, but then it's your own fault if you don't set it. Actually, the example ini files could even start with a friendly reminder that date.timezone should be set. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #81245 — Bob Weinand — 2015-01-27T15:39:27+00:00 URL: https://externals.io/message/81184#81245 · In reply to: #81244 > Am 27.01.2015 um 16:27 schrieb Matteo Beccati : > > > > […] > > Well, if the distro sets display_errors = Off but doesn't also set a proper timezone, I would dare to say it's a bug in their packages. > > Vanilla PHP doesn't do that; it does if you blindly use php.ini-production, but then it's your own fault if you don't set it. > > Actually, the example ini files could even start with a friendly reminder that date.timezone should be set. Not arguing here. I'm on your side here, we can give the timezone a better visibility in the ini without problems. The point is just to have `date()` (with UTC obviously) usable without getting warned in a simple ./sapi/cli/php -r '/* something with `date()` */' call. And no, I don't want to always forget to explicitly set "-ddate.timezone=UTC". It's not comfortable that way. Bob --- ## #81246 — Matteo Beccati — 2015-01-27T15:51:47+00:00 URL: https://externals.io/message/81184#81246 · In reply to: #81245 > > […] > > Not arguing here. I'm on your side here, we can give the timezone a better visibility in the ini without problems. Good :) > The point is just to have `date()` (with UTC obviously) usable without getting warned in a simple ./sapi/cli/php -r '/* something with `date()` */' call. And no, I don't want to always forget to explicitly set "-ddate.timezone=UTC". It's not comfortable that way. So, you'd prefer to make life harder for end users in order to make life easier to those calling sapi/cli/php without a php.ini. To me, it doesn't sound like a good plan, sorry. I don't get why echo 'date.timezone=UTC' >> $prefix/lib/php.ini isn't comfortable enough for you. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ --- ## #81260 — Pierre Joye — 2015-01-27T20:16:27+00:00 URL: https://externals.io/message/81184#81260 · In reply to: #81210 > > > > > […] > > That would be nice, but it's unfortuntately not really possible. You > can't find out what timezone the OS is using in a portable way. Not even > among different linux distributions, let alone having Windows in the > mix. We tried this before, and because it caused so many issues, the > current warning was added (instead of trying to guess a timezone). Either we get a valid one at install time or we bail out during make install. Do not worry about windows here, no biggie either. I am not saying we must do that but it is by far friendlier that we do now or what it is proposed. > cheers, > Derick