Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67535 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82769 invoked from network); 27 May 2013 03:28:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 May 2013 03:28:33 -0000 Authentication-Results: pb1.pair.com header.from=kris.craig@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=kris.craig@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.182 as permitted sender) X-PHP-List-Original-Sender: kris.craig@gmail.com X-Host-Fingerprint: 74.125.82.182 mail-we0-f182.google.com Received: from [74.125.82.182] ([74.125.82.182:53191] helo=mail-we0-f182.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4D/F9-32733-FD2D2A15 for ; Sun, 26 May 2013 23:28:32 -0400 Received: by mail-we0-f182.google.com with SMTP id q57so3809993wes.13 for ; Sun, 26 May 2013 20:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1n4MqYExBmIVbFS1+iL2IN755vfGz3SrMIwIIkGsUbw=; b=WP/Q+qHSuth0of4qj9uXlVkZ2SZI3gmqUAcP4hJhF3MBtzK0v5i+5t7Tqzob4zHz3X B4lcrDQNV9dQ23PQ6/aIKygS6HyISk5LSTK8jP4aedPhMfNq+c0wW9zP0ZTDhEirz3i/ ZoZWCjzmhQNCbR+dbjdnZNaXwrAGpJO62ihxrs7EZ43k0CPTYdIw6b0TMYmFoFydWkEP QJLSU52iIga5ABkw/nx3ODf2+FYW4N4GIEiq3tthczB7pOFZxWhQMdkORWioeSJjMrse 98ctrIqkxQAW6jvPAzedXPLfGIO6KJAuGRm8qgLAF4/Si9FrRgo5LfywkIt6n3K1rhIP 8eAQ== MIME-Version: 1.0 X-Received: by 10.180.36.147 with SMTP id q19mr6813478wij.26.1369625308966; Sun, 26 May 2013 20:28:28 -0700 (PDT) Received: by 10.194.90.39 with HTTP; Sun, 26 May 2013 20:28:28 -0700 (PDT) Received: by 10.194.90.39 with HTTP; Sun, 26 May 2013 20:28:28 -0700 (PDT) In-Reply-To: <1445582130.20130526204520@cypressintegrated.com> References: <51A092FC.4010700@wikimedia.org> <51A1AF3E.5000704@sugarcrm.com> <51A1F701.4080706@lsces.co.uk> <1287105095.20130526154318@cypressintegrated.com> <1445582130.20130526204520@cypressintegrated.com> Date: Sun, 26 May 2013 20:28:28 -0700 Message-ID: To: Sanford Whiteman Cc: Pierre Joye Content-Type: multipart/alternative; boundary=e89a8f502e7204336204ddaabe0d Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale? From: kris.craig@gmail.com (Kris Craig) --e89a8f502e7204336204ddaabe0d Content-Type: text/plain; charset=ISO-8859-1 Again, why can't we just bypass this whole argument by adding a configure option? Something like --date.default_timezone="America/Los_Angeles"? It could then build that in so it'll assume that if there's no php.ini or if it's just not set in there. Problem solved, everybody's use-case covered. --Kris On May 26, 2013 5:46 PM, "Sanford Whiteman" < swhitemanlistens-software@cypressintegrated.com> wrote: > > 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. > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > --e89a8f502e7204336204ddaabe0d--