Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67568
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8MpnnDK5jdRp_x3WipWKNH+nBNMBZ0tJW1rmX+kOjG3_VC2g@mail.gmail.com>
References: <CAH8Mpnkbhge8kS8Nv7Or9fgfxz2A0EXmLNEg=4c=D5zjaneSgg@mail.gmail.com>
	<CAEZPtU77ASyV7nG5Zrrk-P_Y-EKm+dMWX25dNZswi7W+Hd7Zgg@mail.gmail.com>
	<CAH8MpnnDK5jdRp_x3WipWKNH+nBNMBZ0tJW1rmX+kOjG3_VC2g@mail.gmail.com>
Date: Mon, 27 May 2013 17:12:23 -0700
Message-ID: <CAKOpQSx5U=wrff+EQKvBSjb2GV2dYX68_j34Y_UpgcoEGh4jsg@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b6d9a8890ac9704ddbc1e6b
Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
From: kris.craig@gmail.com (Kris Craig)

--047d7b6d9a8890ac9704ddbc1e6b
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 27, 2013 at 4:35 PM, Daniel Lowrey <rdlowrey@gmail.com> wrote:

> 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 Monday, May 27, 2013, Pierre Joye wrote:
>
> > 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 their date()
> > > 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

--047d7b6d9a8890ac9704ddbc1e6b--