Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.188 cause and error)
Message-ID: <504709CE.1000004@lsces.co.uk>
Date: Wed, 05 Sep 2012 09:14:06 +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> <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> <CAArmra2L5uHUdqksMM2572iAMQAvFW3zogSeKT=cYxnihRYfdA@mail.gmail.co
 m>
In-Reply-To: <CAArmra2L5uHUdqksMM2572iAMQAvFW3zogSeKT=cYxnihRYfdA@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:
> 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)

Just working through another backlog of 'todo' items.

Your current RFC includes -0500 in the examples, but that is purely due to your 
own setup. This is the real problem here since you can't take a date/time string 
and clone a new object. You have to define a DateTimeZone object prior to 
creating the DateTime object. You have 'America/Chicago' set as your default 
timezone, and that is fine for your local working, but part of Derick's 
objection is that how this all hangs together is always a two stage process.

Now if you can make the above string clone a matching DateTime/DateTimeZone 
object pair, then part of the objection would go, but *I* would still object to 
any default here since it's just as likely you want to leave the timezone off 
and handle it separately as include it in an output string.

Also it is worth noting that DateTime::__construct specifically ignores the 
$timezone parameter when the date string includes an offset! This may well be 
considered a bug and perhaps $timezone parameter should take priority, but it's 
all these little things that get missed when one 'just fills in a missing 
function' ... someone just taking the default string and trying to create a new 
date object for a different timezone might get caught out, so that particular 
point should be included in any documentation. Actually currently the returned 
string would not work anyway?

The RFC is 'needs more work' but I still feel that adding this 'shortcut' will 
create more problems than it will provide any benefit.

-- 
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