Having started this thread I'd like to focus the discussion so we can
actually get somewhere. Otherwise opinions will keep streaming in ad
nauseum without any real progress.
At issue here is not whether UTC makes sense as a default. The
question is also not how we can automate the install process via
package managers to set an appropriate default timezone. Additionally,
this has nothing to do with perceived "laziness" on the part of people
who don't want to add a line in the .ini file or define the default in
their scripts.
My problem with the current behavior is that it essentially forces
the use of an .ini file by triggering an error if no default is
assigned. As far as I know there is no other extension that punishes
you for not using an .ini file. Further, my argument is that this
behavior is undesirable and treats the CLI as a second class citizen
by assuming PHP is only used as a web framework. I frequently have
good reasons to run without an .ini file and this error is a roadblock
to using PHP to program (and not to make web pages).
Now, as far as I can tell the only argument put forward to justify
triggering the error is (summarized): many people are too stupid to
set a timezone and don't understand why the results of their date()
calls are different from their own timezone. This results in many
erroneous bug reports.
So the question I would like to see addressed is this:
Is user stupidity a sufficient reason to punish people running without
an .ini file (php -n)?
If there are reasons besides "we get tons of mistaken bug reports and
we need to cater to the very worst PHP programmers," I have yet to see
them expressed.
My problem with the current behavior is that it essentially forces
the use of an .ini file by triggering an error if no default is
assigned.
No it does not. You can use:
- php -d ...
- date_default_timezone_set
Now, as far as I can tell the only argument put forward to justify
triggering the error is (summarized): many people are too stupid to
set a timezone and don't understand why the results of theirdate()
calls are different from their own timezone. This results in many
erroneous bug reports.
It is not one of the arguments. The arguments are bad TZ, invalid TZ
or inconsistent in system's TZ, which causes hard to catch bugs (and
not possible to fix), non portable code (if you rely on a bad TZ), to
name only a few.
And I stop here for this discussion, I do not see any new arguments on
both sides and a default TZ will very unlikely happen. Packagers could
deal with that easily and application developers as well.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I understand that you can use php -d, but this is not a portable solution.
My specific use case is running a libevent-based HTTP server and I cannot
even run unit test suites without an .ini file because of this warning. Why
does PHP force me to include configuration directives that it clearly
doesn't need to function correctly? Forcing users to specify additional
command line options on every execution is no less pointless than than
requiring an .ini file where none is needed. A user's time zone setting is
simply not a language-level concern. Nor is a user's inability to
understand how timezones work. I appreciate Derrick's work on the extension
but I have yet to see any valid justification for triggering an error when
no error actually exists.
On Tue, May 28, 2013 at 12:57 AM, Daniel Lowrey rdlowrey@gmail.com
wrote:My problem with the current behavior is that it essentially forces
the use of an .ini file by triggering an error if no default is
assigned.No it does not. You can use:
- php -d ...
- date_default_timezone_set
Now, as far as I can tell the only argument put forward to justify
triggering the error is (summarized): many people are too stupid to
set a timezone and don't understand why the results of theirdate()
calls are different from their own timezone. This results in many
erroneous bug reports.It is not one of the arguments. The arguments are bad TZ, invalid TZ
or inconsistent in system's TZ, which causes hard to catch bugs (and
not possible to fix), non portable code (if you rely on a bad TZ), to
name only a few.And I stop here for this discussion, I do not see any new arguments on
both sides and a default TZ will very unlikely happen. Packagers could
deal with that easily and application developers as well.Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I understand that you can use php -d, but this is not a portable solution.
My specific use case is running a libevent-based HTTP server and I cannot
even run unit test suites without an .ini file because of this warning. Why
does PHP force me to include configuration directives that it clearly
doesn't need to function correctly? Forcing users to specify additional
command line options on every execution is no less pointless than than
requiring an .ini file where none is needed. A user's time zone setting is
simply not a language-level concern. Nor is a user's inability to
understand how timezones work. I appreciate Derrick's work on the extension
but I have yet to see any valid justification for triggering an error when
no error actually exists.On Tue, May 28, 2013 at 12:57 AM, Daniel Lowrey rdlowrey@gmail.com
wrote:My problem with the current behavior is that it essentially forces
the use of an .ini file by triggering an error if no default is
assigned.No it does not. You can use:
- php -d ...
- date_default_timezone_set
Now, as far as I can tell the only argument put forward to justify
triggering the error is (summarized): many people are too stupid to
set a timezone and don't understand why the results of theirdate()
calls are different from their own timezone. This results in many
erroneous bug reports.It is not one of the arguments. The arguments are bad TZ, invalid TZ
or inconsistent in system's TZ, which causes hard to catch bugs (and
not possible to fix), non portable code (if you rely on a bad TZ), to
name only a few.And I stop here for this discussion, I do not see any new arguments on
both sides and a default TZ will very unlikely happen. Packagers could
deal with that easily and application developers as well.Cheers,
Pierre
@pierrejoye | http://www.libgd.org
At the risk of sounding like a broken record, adding a configure option
would render this entire debate moot. PHP's behavior without the option
specified would be identical to the way it is now. With the option
specified, PHP would assume a default timezone if one is not set in
php.ini, including if php.ini doesn't exist at all. So, bug tracker
wouldn't get filled-up with default timezone behavior confusion like before
and people like Daniel would be able to easily do their thing without
php.ini and without having to change any of their runtime parameters or
muck around with the source code. It's win-win.
I'd be happy to draft an RFC for this. I really don't see the point in
dragging on this heated argument when we can so easily skip around it
altogether.
--Kris
Pierre Joye wrote:
And I stop here for this discussion, I do not see any new arguments on
both sides and a default TZ will very unlikely happen. Packagers could
deal with that easily and application developers as well.
Isn't the point here that this only became a problem when the NEED for a default
time zone was forced on us? What I should be saying is not that UTC should be
the default, but rather running as PHP used to without any regard for a timezone
should be the default. Since many people simply don't understand the
ramifications of needing to add daylight saving management into their
applications. Treat a simple UTC default as 'server clock' so that 6PM is 6PM
any time of the year and many of the problems go away?
Only enable timezone management when you need to start to take care of users in
different timezones at which time one is forced to manage the shifts of time
properly. Why do the people who are only running with local time need to worry?
The second you start to use timezones you need to set things up properly yourself!
Add of cause the fact that it's not just using DateTime with a timezone that
causes a problem, but the bugs which remain in it are another area that can
cause problems.
--
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