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 https://wiki.php.net/rfc/date.timezone_warning_removal
Bob
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
Hi
2015-01-27 1:34 GMT+01:00 Bob Weinand bobwei9@hotmail.com:
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 https://wiki.php.net/rfc/date.timezone_warning_removalBob
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
Hi Kalle and all,
On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen kalle@php.net
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_DEPRECATEDfor 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
Hi Kalle and all,
On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen kalle@php.net
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_DEPRECATEDfor 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 feelE_WARNINGis
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
On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen kalle@php.net
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_DEPRECATEDfor 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 feelE_WARNINGis 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.
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
On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen kalle@php.net
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_DEPRECATEDfor 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 feelE_WARNINGis 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.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
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 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/
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.
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.
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
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
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
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
I'd like to request removal of the date.timezone warning.
Here is the RFC:
https://wiki.php.net/rfc/date.timezone_warning_removal
https://wiki.php.net/rfc/date.timezone_warning_removalThe 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
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
https://wiki.php.net/rfc/date.timezone_warning_removalThe 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
I'd like to request removal of the date.timezone warning.
Here is the RFC:
https://wiki.php.net/rfc/date.timezone_warning_removal
https://wiki.php.net/rfc/date.timezone_warning_removalThe 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.
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
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 <
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
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
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 <
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?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
> > 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
>
So let the distros solve it ... and allow PHP to still be usable without an
ini file.
Nikita
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/
Am 27.01.2015 um 12:49 schrieb Matteo Beccati php@beccati.com:
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/
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
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/
Am 27.01.2015 um 16:27 schrieb Matteo Beccati php@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.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
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.
Good :)
The point is just to have
date()(with UTC obviously) usable without getting warned in a simple ./sapi/cli/php -r '/* something withdate()*/' 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/
I'd like to request removal of the date.timezone warning.
Here is the RFC:
https://wiki.php.net/rfc/date.timezone_warning_removal https://wiki.php.net/rfc/date.timezone_warning_removal
Absolutely not.
cheers,
Derick