Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67566
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8Mpnkbhge8kS8Nv7Or9fgfxz2A0EXmLNEg=4c=D5zjaneSgg@mail.gmail.com>
References: <CAH8Mpnkbhge8kS8Nv7Or9fgfxz2A0EXmLNEg=4c=D5zjaneSgg@mail.gmail.com>
Date: Tue, 28 May 2013 01:16:17 +0200
Message-ID: <CAEZPtU77ASyV7nG5Zrrk-P_Y-EKm+dMWX25dNZswi7W+Hd7Zgg@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Re: date.timezone E_WARNING -- Really necessary? What's
 the rationale?
From: pierre.php@gmail.com (Pierre Joye)

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