Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62737
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain meetme.com designates 74.125.149.197 as permitted sender)
MIME-Version: 1.0
Sender: wfitch@meetme.com
In-Reply-To: <5044A261.10901@lsces.co.uk>
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>
	<5044A261.10901@lsces.co.uk>
Date: Mon, 3 Sep 2012 09:04:02 -0400
Message-ID: <CAArmra2L5uHUdqksMM2572iAMQAvFW3zogSeKT=cYxnihRYfdA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net >> PHP internals" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=14dae9d24d309ae20204c8cbc6d1
Subject: Re: [PHP-DEV] RFC for Adding __toString to DateTime
From: willfitch@php.net (Will Fitch)

--14dae9d24d309ae20204c8cbc6d1
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 3, 2012 at 8:28 AM, Lester Caine <lester@lsces.co.uk> wrote:

> 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.


Hi, Lester - I'll update the patch and RFC to include this format.  This is
the format I'll use unless others have a better approach:

2012-09-01T00:00:00-0500 (America/Chicago)


>
>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=**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<http://rainbowdigitalmedia.co.uk>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--14dae9d24d309ae20204c8cbc6d1--