Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67556
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.20.127 cause and error)
Message-ID: <51A32E3E.6090506@lsces.co.uk>
Date: Mon, 27 May 2013 10:58:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17
MIME-Version: 1.0
To: "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
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> <51A2D395.5030302@sugarcrm.com> <1022965181.20130527011024@cypressintegrated.com> <51A2FD10.7030906@gmail.com> <293168642.20130527032001@cypressintegrated.com> <6c6c2a5a-8762-48fc-9a71-0e9c5dca82a5.maildroid@localhost> <1331934391.20130527050005@cypressintegrated.com>
In-Reply-To: <1331934391.20130527050005@cypressintegrated.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's
 the rationale?
From: lester@lsces.co.uk (Lester Caine)

Sanford Whiteman wrote:
> 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).

Actually I probably am saying 'default to UTC for display' but simply drop the 
'UTC' bit altogether! If you want a site to run in a single timezone, then using 
timezone settings just complicates things. In particular when trying to set a 
meeting in 6 months time which is the one that caught me out initially. Simply 
using a raw unadulterated time is the safest way of managing sites that have no 
real interest in daylight saving. As soon as you NEED to manage timezones/DLS, 
then the starting point is always to run the server as UTC and manage everything 
else from that. Running the server on any other setting and trying to store UTC 
data introduces yet another unnecessary complication.

Adding tz as a requirement was the basic mistake here. It has no place on many 
systems.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk