Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67532
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender)
Date: Sun, 26 May 2013 15:43:18 -0400
Reply-To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Message-ID: <1287105095.20130526154318@cypressintegrated.com>
To: Lester Caine <internals@lists.php.net>
In-Reply-To: <51A1F701.4080706@lsces.co.uk>
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> <51A1F701.4080706@lsces.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman)

> Until a user logs into a site and provides the data of their current
> daylight saving 'location'

Which we might as well assume will never happen. I know our users
don't waste time on this step if it's optional, and I'm not going to
push an E_FATAL onto them by saying I'm not going to show them
timestamps at all unless they set their TZ. Nor am I going to make
them see stuff in UTC, because they'll just say, "This site's borked"
and laugh at us and/or assume we're in the UK and go on with their
work, instead of seeking a solution. And as I note below, for us at
least, the solution is not to have them set their "true" timezone.

> If you are assuming a server is in a single time-zone, then it makes
> even less sense to use anything other than UTC and ignore timezones
> altogether? 

Not always, because of something Tim alludes to: principal geographic
interest. We run a multi-tenant architecture, and each tenant has a
home office in a US city. The time zone at HQ is typically the time
zone on which work schedules/deadlines are based, and their users
don't always *want* to see their offset applied as they travel to
Chennai or Paris for a couple of days. They'll change their
phone/watch/laptop timezone, yeah, but they're collaborating with
people in the US timezone and they don't want to face constant offsets
and am/pm confusion whenever they log in. Even subcontractors
permanently residing in another city are usually better off with the
HQ timezone, because they are racing to submit stuff by HQ's close of
business, not their own (which could be three business days later).

It is true that some of our tenants share the same PHP.INI, so in this
respect the INI value itself is not useable, but the principle still
applies. A more sensible default than UTC can usually be found using
domain and corporate knowledge. For our userbase, setting to New York
time by default (that's our time) still would be less confusing than
UTC. US residents have an immediate grasp of the West Coast/East Coast
3-hour shift but wouldn't grok the international offsets.

As Tim and Richard said, the "most interesting" timezone has no
intrinsic relationship to the server timezone given cloud
computing/colocation.

Anyway, the problems raised on this thread have made me think more
about how we let users handle time, so I appreciate the discussion and
may change my take over the next few days.

-- Sandy