Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67533
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1287105095.20130526154318@cypressintegrated.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>
	<CAKUjMCW4367kFCwSUOVe6H7+pdSd6f1gD7jeyYgY7GXuyqemGQ@mail.gmail.com>
	<51A1F701.4080706@lsces.co.uk>
	<1287105095.20130526154318@cypressintegrated.com>
Date: Mon, 27 May 2013 00:56:49 +0200
Message-ID: <CAEZPtU6OjOASbNyuXxrpu27eqBMRny_-N4h1w3MNHYpD1QNOLA@mail.gmail.com>
To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Cc: Lester Caine <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
From: pierre.php@gmail.com (Pierre Joye)

hi!

On Sun, May 26, 2013 at 9:43 PM, Sanford Whiteman
<swhitemanlistens-software@cypressintegrated.com> wrote:
>> 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.

Then set the TZ to UTC or whatever else fits your needs. Server side
TZ from a php point of view can be set to whatever you want, be at the
php.ini level or in your application configuration (and call the
appropriate function).

>> 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,

Let the user has an option and use this option to set the right TZ at
the beginning of each request. That's what every tool I know does.

That being said, I do not knwow which apps you use to organize your
time plans but all we used here do the conversion for you. Users hate,
me included, to have meetings and other time related activities
notifications using a different TZ that the one where I am (which can
change).


> 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.

It can be set per vhost, per app, etc.

> 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.

Then do it this way:

- default in php.ini
- override default is an user has his TZ option set

> As Tim and Richard said, the "most interesting" timezone has no
> intrinsic relationship to the server timezone given cloud
> computing/colocation.

And never had, that's how web apps work :)

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org