Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67554 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23618 invoked from network); 27 May 2013 09:00:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 May 2013 09:00:50 -0000 Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [173.1.104.101] ([173.1.104.101:65004] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F7/C1-32733-0C023A15 for ; Mon, 27 May 2013 05:00:49 -0400 Received: from localhost ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id MOB52045 for ; Mon, 27 May 2013 02:00:45 -0700 Date: Mon, 27 May 2013 05:00:05 -0400 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <1331934391.20130527050005@cypressintegrated.com> To: Lester Caine In-Reply-To: <6c6c2a5a-8762-48fc-9a71-0e9c5dca82a5.maildroid@localhost> References: <51A092FC.4010700@wikimedia.org> <51A1AF3E.5000704@sugarcrm.com> <51A2D395.5030302@sugarcrm.com> <1022965181.20130527011024@cypressintegrated.com> <51A2FD10.7030906@gmail.com> <293168642.20130527032001@cypressintegrated.com> <6c6c2a5a-8762-48fc-9a71-0e9c5dca82a5.maildroid@localhost> 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) > And if you think 'London time' is UTC then you will get just as > many problems half of tbe year. I said the *end user will assume* UTC timestamps are London time. Not that London time is UTC. People try to fit what they see into something they know. People in US-East see stuff 4-5 hours off, that's what they think. I hear it all the time: "I think they're in the UK." A one-hour shift doesn't make them instantly have a come-to-UTC moment. Anyway, that's the unavoidable consequence of defaulting to UTC for storage and display. That's why using "domain time" as the display default is preferable, when there is a relevant one, further allowing people to set their tz as applicable for their session or user profile (profile == default for future sessions). I do not believe in forcing people to choose this setting before passing authentication in any old web app, as putting up such a barrier can be obtrusive; also, for our apps, it can lead to confusion because the domain time is always known, so we put the option in the user's control panel but don't lead them to it. I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default and changed only based on end-user input. I think there are five legitimate levels of consideration (storage tz, sitewide display tz, domain/corporate display tz, stored user profile tz, and transient session tz). -- S.