Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67541
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.47 as permitted sender)
Message-ID: <51A2FD10.7030906@gmail.com>
Date: Mon, 27 May 2013 08:28:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: internals@lists.php.net
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> <CAKUjMCW4367kFCwSUOVe6H7+pdSd6f1gD7jeyYgY7GXuyqemGQ@mail.gmail.com> <51A2D395.5030302@sugarcrm.com> <1022965181.20130527011024@cypressintegrated.com>
In-Reply-To: <1022965181.20130527011024@cypressintegrated.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's
 the rationale?
From: leafnode@gmail.com (=?UTF-8?B?TGVzemVrIEtydXBpxYRza2k=?=)

On 2013-05-27 07:10, Sanford Whiteman wrote:
> In general, I use the principle of "domain time." If a site serves a
> (stock) exchange that closes at 4:00pm Eastern time, people hitting
> that site from all over the world are not going to necessarily
> remember that close-of-business is such-and-such UTC or such-and-such
> Tokyo. At best they will need to see the times side-by-side (like the
> example of world clocks on the wall). And the fact that our clients'
> end users see the time at corporate HQ by default is just another
> manifestation of the domain time principle. Some domains don't pretend
> to be timeless and spaceless. Note this doesn't mean all client
> software is ignoring "roaming time" -- we send iCal invites in UTC of
> course -- nor that, in our case, users they can't change what the site
> displays if they insist (though they rarely do). It's a question of
> the best-fit default.
>
> Of course, there are many sites for which the best default *is*
> user-defined or UTC, whichever is found first. It's just not a
> universal assumption.

As you have said - there are some use cases, where non-UTC TZ setting is 
important. But do you think that people running this software wouldn't 
know that they have to set a proper time zone in ini file? Or at least 
in app configuration? In my opinion UTC is a good compromise. From my 
experience, the problem divides into two categories:
a) apps that display time on pages and users might be wondering why the 
time has some shift - it's not a critical setting; it might be set, but 
without this no key features are borked;
b) app is deeply set in a geographic location, like aforementioned stock 
exchange - proper setting is critical.

In a) setting TZ to UTC is not making the website broken - it's just a 
glitch. Admin can fix the setting if anyone notices the problem - yes, 
that might stem a lot of bug reports, but as it was with 
register_globals. In b) admin should really know better that he has to 
set this in ini.

Also, in my opinion, responsibility for the setting should be moved from 
system administrator to application developer. If app is time-set, it 
should have a proper setting for this.

It was said before that there aren't many systems that require you to 
set this setting. It was also bashed that "you don't know all the apps". 
Yeah, maybe I don't know all of them, but I've installed Python, Ruby 
and Java apps (which I assume comprise most of web app environments - 
ASP aside, but I suppose in this case it's even easier to get proper TZ 
from environment), and I was never forced to set _any_ option because 
otherwise my app would be showing some nasty warnings. But that's only 
my experience.

--Leszek