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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
