Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
Reply-To: RQuadling@GMail.com
In-Reply-To: <51A1AF3E.5000704@sugarcrm.com>
References: <CAH8Mpnmin=caSgrOQYZD23q80eZEVO4jyRUAYKNc2URU-2RVnQ@mail.gmail.com>
 <51A092FC.4010700@wikimedia.org> <CAEZPtU7fZ2xn3b9jTeYWv1JHSRxMwSpZRSo0pr37PTh4gc7K4w@mail.gmail.com>
 <CAFMT4Nqyf0srd=vhZoWAN=igq8y1Y7MQZdoNDO6kwgS6FE-VGg@mail.gmail.com>
 <CAFMT4NrdTosBt6waY0U2TBCgq2xRC=DGyUcryngKVpM0yGfY6g@mail.gmail.com> <51A1AF3E.5000704@sugarcrm.com>
Date: Sun, 26 May 2013 12:41:53 +0100
Message-ID: <CAKUjMCW4367kFCwSUOVe6H7+pdSd6f1gD7jeyYgY7GXuyqemGQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Levi Morrison <morrison.levi@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10d1dbf5a58b04dd9d854f
Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
From: rquadling@gmail.com (Richard Quadling)

--047d7b10d1dbf5a58b04dd9d854f
Content-Type: text/plain; charset=UTF-8

On 26 May 2013 07:44, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>
> > I did not do a very good job explaining what I meant. I meant to say
> > that requiring the timezone to be set prevents you from running
> > without an ini file without any warnings. This is a big annoyance.
>
> If you insist on using the tool in a wrong way, you will be annoyed as
> the tool would not work in a way you want it to work. The right way is
> to set up the ini file. It takes about 2 seconds.


Not in direct response to the above point, but more of a comment on this
thread, and the various reappearances of this thread.

As I understand things, some of the issues with asking the OS for the
timezone are:

1 - The OS may not present a timezone in a way that PHP can easily access
in a consistent way (i.e. too many flavours, mechanisms, etc.).
2 - The machine's local time and/or timezone may not be set correctly
anyway.

A point come to mind, in addition to all of this (and I'm not an expert,
but this may be important) ...

As more and more site/services are being hosted in the cloud, allowing
requests to be handled locally geographically, in different timezones, does
it make ANY sense in setting a timezone at all other than UTC?

From what I can see, a server (which may not be under our control) COULD
have pretty much any time and/or timezone on it. So even if we DO set a
timezone in PHP, the time could still be out and that really isn't a good
thing.

If setting the timezone is so critical that a warning MUST be given when it
is not set and that by ignoring the warning (either because of a lazy dev
or a dev who cannot see the warning due to shared setup or something else)
the scripts running that rely on accurate datetimezone, why not make this a
fatal error. Yes. I know you've all jumped off your chairs to complain, but
either PHP MUST have this setting appropriately, or it can live without it.
The grey area of "PHP can run, but your results, well, meh!" does not fit
well.

If all it takes is 2s to set the INI file, why bother running without the
setting.


Is there any process that could be run that would do the following ...

1 - Determine the machines current date/time.
2 - Determine the machines current timezone (or lack of ability to return
that information).
3 - Verify the local time with a known/accurate/maintained time server.
4 - From all of this, make an accurate decision or best guess as to what
the timezone should be.
5 - Set an entry in the php.ini file appropriate for the guessed_timezone.

So, the warning COULD be given, but allow a dev to run a PHP Team sourced
process to determine where in the world the server is (I have access to
servers all over Europe. I don't know the timezones that they are all in
initially and had to work to confirm that the machine date/time/timezone
was accurate. It would seem that a script could do this better,
consistently, etc.).

Just an idea on trying to solve this. If it could be automated, essentially
whatever manual steps a dev would take to accurately set the timezone on an
unknown server, then this process would certainly seem to be useful. But
only because PHP gives a warning that the lack of the timezone is an issue.

Regards,

Richard.


-- 
Richard Quadling
Twitter : @RQuadling
EE : http://e-e.com/M_248814.html
Zend : http://bit.ly/9O8vFY

--047d7b10d1dbf5a58b04dd9d854f--