Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67534 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 73662 invoked from network); 27 May 2013 00:46:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 May 2013 00:46:06 -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:62704] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BF/A8-32733-CCCA2A15 for ; Sun, 26 May 2013 20:46:05 -0400 Received: from localhost ([216.220.114.66]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id MFV39101 for ; Sun, 26 May 2013 17:46:01 -0700 Date: Sun, 26 May 2013 20:45:20 -0400 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <1445582130.20130526204520@cypressintegrated.com> To: Pierre Joye In-Reply-To: References: <51A092FC.4010700@wikimedia.org> <51A1AF3E.5000704@sugarcrm.com> <51A1F701.4080706@lsces.co.uk> <1287105095.20130526154318@cypressintegrated.com> 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) > 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). Was there something that indicated I don't know how to do this? I have always done it and have no problem with it. I don't mind how it works now at all. Lester's point is UTC is the right default (and thus the battle over the E_WARNING should be settled that way). I happen to agree with that part, but disagree from heavy experience with the notion that "UTC or end-user-selectable" is the only choice you have once you set a value. > 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. (a) You don't know all the tools in the world. (b) Please show me how every major web app gives you a clearly visible and encouraged option to set the tz _at the beginning of each session_ (I don't think you mean request). Happy to send screenshots to the contrary. (c) When a web app lets the user change her/his profile parameters (which is certainly common) this is irrelevant to their session (so if they change it when they're in City A, they have to change it again in City B and C as they jump around), (b) on an advanced setup tab somewhere. You're dead wrong if you think traveling telecommuters are always looking at -- let alone want to look at -- their local time. > 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). Well... that's not the way every set of organizations work, hate to break it to ya. For some apps the Chennai office is at least in part on San Francisco time. This can be because they remote in and don't constantly set the TZ in their Citrix session, or because they use a web app and, like most real users, can't be bothered to find the setting and are not in any way nagged to do so. This doesn't mean that some scheduler app doesn't display their local time _as well_ as the origin time. But have you ever seen the ol' wall of world clocks? There's a reason for that. I like to work that way and so to lots of humans. > Then do it this way: > - default in php.ini > - override default is an user has his TZ option set I don't need these instructions, which are quite condescending. (And if you think *I* need them, how can this coexist with the fantasy that non-programmers always tightly manage their TZ?) -- S.