Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62838
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: <50476F68.4070902@lsces.co.uk>
Date: Wed, 05 Sep 2012 16:27: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: PHP internals <internals@lists.php.net>
References: <CAArmra3oN6NMn-CPn95piNQeKN1LJ7nq3baj1B0z6pCCPZX0VQ@mail.gmail.com> <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.com> <504709CE.1000004@lsces.co.uk> <CAArmra2pc0tiOqnpOxur-0WhnSfUKj0OjL7Nw64ARL5i7b0tWQ@mail.gma
 il.com>
In-Reply-To: <CAArmra2pc0tiOqnpOxur-0WhnSfUKj0OjL7Nw64ARL5i7b0tWQ@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:
>
> On Wed, Sep 5, 2012 at 4:14 AM, Lester Caine <lester@lsces.co.uk
> <mailto:lester@lsces.co.uk>> wrote:
>
>     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 DaTime 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 format being suggested (ISO8601 + TZ name) won't work without addressing the
> concern you mentioned as well as correctly parsing the TZ name.
>
>     The RFC is 'needs more work' but I still feel that adding this 'shortcut'
>     will create more problems than it will provide any benefit.
>
> I'm currently working on revamping the RFC and offering up two separate
> solutions.  You are right that it's going to be difficult to please everyone,
> but I do want a solution that can be acceptable to most.  If that ends up being
> no solution at all, so be it.  I do believe through enough conversation and
> potentially adjusting DateTime's current behavior (e.g. the TZ point you brought
> up), a solution can be reached.
>
> It's important to keep one of Derick's points in mind as well -
> https://wiki.php.net/rfc/datetime_and_daylight_saving_time.

That is actually part of the reason all my internal processing is only ever UTC. 
so I only use the timezone to display data so does not affect you on that side. 
However I know that there is a black hole if someone does try and enter a date 
and time in that 1 hour missing window :)

-- 
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