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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
