Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62733
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.128 cause and error)
Message-ID: <5044A261.10901@lsces.co.uk>
Date: Mon, 03 Sep 2012 13:28:17 +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 >> PHP internals" <internals@lists.php.net>
References: <CAArmra3oN6NMn-CPn95piNQeKN1LJ7nq3baj1B0z6pCCPZX0VQ@mail.gmail.com> <CAEZPtU7AGKYcfHBcf8ZCrAufF=MUu=75WDE28KAmhihDEFsHmw@mail.gmail.com> <50435ABE.4010308@ajf.me> <CAEPJdunLROfKuGNu3AjCjLY3KmQ4DyHJi04WkENyVg6zapVrAg@mail.gmail.com> <50436412.7010802@ajf.me> <alpine.DEB.2.02.1209021814580.25835@whisky.home.derickrethans.nl> <5043C3E9.2010105@ajf.me> <alpine.DEB.2.02.1209022145220.25835@whisky.home.derickrethans.nl> <5043C5AF.3060701@ajf.me> <alpine.DEB.2.02.1209022149540.25835@whisky.home.derickrethans.nl> <5043C74C.8020400@ajf.me> <alpine.DEB.2.02.1209022213180.25835@whisky.home.derickrethans.nl> <CAPg3Xx+YDJQ2buTJN9OBJ6fos+mDdxD9wdWueOZ9+d_qyuP3iA@mail.gmail.com> <5043D8C0.3020802@lsces.co.uk> <CAArmra3Oj7LfMKOf9mZpYnd6xzdhUvUPOOJLS69EbMwcc7EkNA@mail.gmail.com> <alpine.DEB.2.02.1209030912170.25835@whisky.home.derickrethans.nl> <CAArmra12C2Y7SCJD9xoCBqveLsAQLyvQWaF4hpYYu7+hu8w9uA@mail.gmail.com> <alpine.DEB.2.02.1209031251110.25835@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.02.1209031251110.25835@whisky.home.derickrethans.nl>
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)

Derick Rethans wrote:
>> You have an accurate representation of the ISO format - which does not
>> >specify the string representation of a timezone, but rather the offset of
>> >UTC.  This is not lossy.
> Yes it is! You can't go back from an UTC offset to a timezone string.
> Hence: lossy.

Exactly ...

Will - if you are displaying a date, and then looking for a UTC time 6 months 
later you need the daylight saving setting. Personally I get around this problem 
by displaying a 'local client time' based on extra details provided by the 
client login. A server default is never going to be the right answer unless you 
simply switch off ALL timezone working and only use local time, in which case 
your proposal could work - as long as it NEVER displays offsets. Most problems 
on systems that DO require to correctly manage timezone shifted data come about 
by not running the server with a fixed UTC clock and then trying to map things 
across different timezones. In this situation, the browser time offset is 
useless and the main reason that Derick is flagging ISO format as lossy. It can 
never give you the correct data in six months time where daylight saving shifts 
comes in and using it here is just exacerbating that problem by continuing to 
reinforce a wrong 'standard'.

So the server 'default' local time needs to work of extra timezone data rather 
than the local clock. Any display MUST then show timezone rather than just an 
arbitrary offset or simply UTC time ... with a UTC flag to confirm that.

-- 
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