Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62661
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.125 cause and error)
Message-ID: <50431ECC.9040100@lsces.co.uk>
Date: Sun, 02 Sep 2012 09:54:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120604 Firefox/13.0 SeaMonkey/2.10
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAArmra3oN6NMn-CPn95piNQeKN1LJ7nq3baj1B0z6pCCPZX0VQ@mail.gmail.com> <5042BC3C.7070208@sugarcrm.com> <CAArmra16sTbcYmORDK2mesFOeZxsD=3rAH03S3B_MRJnE8J6Gw@mail.gmail.com>
In-Reply-To: <CAArmra16sTbcYmORDK2mesFOeZxsD=3rAH03S3B_MRJnE8J6Gw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC for Adding __toString to DateTime
From: lester@lsces.co.uk (Lester Caine)

Will Fitch wrote:
>> I'm not sure introducing special state to DateTime for it is the best
>> >way to handle it. Also, most applications would have common date format
>> >- which means since the state is per DateTime object, they'd have to
>> >watch that every object produced would have this property set. I think
>> >it'd be easier to just use DateTime->format() - this way you know what
>> >is produced and it is clear for whoever is reading the code too.
>> >
> Hi, Stas.  This has been on my mind as well.  I've considered that maybe an
> INI wide setting would be beneficial here.  In fact, there are many places
> within applications I've worked on where the format for many DateTime
> objects are the same.  What are your thoughts on that?

Will - while I can understand the desire to bring datetime in line with other 
objects, the amount of trouble some of us have with trying to identify between 
American and English dates and identifying the clients correct time zone does 
make this something of a minefield. As Derick has said, ISO-8601 is not the best 
choice because of the timezone problem, and until browsers actually provide a 
correct timezone setting this is often wrong for half of the year. 'HTTP 
Cookies' does at least include timezone, but I'd not want to use that as a 
default because it's too verbose. I prefer internally to work with UTC time only 
and fix everything to that, and then display in the CLIENT's identified format, 
so a server default setting is a little pointless ... and in my book should be 
simple UTC all the time :)

-- 
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