Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62724
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
In-Reply-To: <alpine.DEB.2.02.1209030912170.25835@whisky.home.derickrethans.nl>
References: <CAArmra3oN6NMn-CPn95piNQeKN1LJ7nq3baj1B0z6pCCPZX0VQ@mail.gmail.com>
	<5042BC3C.7070208@sugarcrm.com>
	<CAArmra16sTbcYmORDK2mesFOeZxsD=3rAH03S3B_MRJnE8J6Gw@mail.gmail.com>
	<alpine.DEB.2.02.1209021233560.25835@whisky.home.derickrethans.nl>
	<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>
Date: Mon, 3 Sep 2012 07:49:43 -0400
Message-ID: <CAArmra12C2Y7SCJD9xoCBqveLsAQLyvQWaF4hpYYu7+hu8w9uA@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: Lester Caine <lester@lsces.co.uk>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec54ee282d1d5b704c8cabc03
Subject: Re: [PHP-DEV] RFC for Adding __toString to DateTime
From: wfitch@meetme.com (Will Fitch)

--bcaec54ee282d1d5b704c8cabc03
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Sep 3, 2012 at 4:16 AM, Derick Rethans <derick@php.net> wrote:

> On Sun, 2 Sep 2012, Will Fitch wrote:
>
> > On Sep 2, 2012 6:08 PM, "Lester Caine" <lester@lsces.co.uk> wrote:
> > >
> > > Peter Cowburn wrote:
> > >>
> > >> Finally, why should "echo $datetime;" be expected to work at all,
> > >> since 95% of the time it's only going to be echo'd plain like that for
> > >> debugging purposes as we'll never pick the "right" format to use in
> > >> everyone's code. When needing to set the "default" (read:
> > >> per-instance) string format with something like setToStringFormat() or
> > >> whatever, that becomes*more*  work than just calling format().
> > >
> > >
> > > Hopefully Will now understands just how problematic his request is, and
> > why it has not been implemented as yet. I'm with you but for a slightly
> > different reason. I never run anything but UTC on the server. So I'm only
> > displaying anything other than UTC when handling a client view of the
> data.
> > So I would normally be calling format with the client timezone data.
> >
> > It is problematic because that is what we choose to make it. Right now,
>  a
> > catchable fatal error is produced. That is problematic. ISO8601 is not
> > lossy nor is UTC.
>
> This tells me you haven't researched this subject properly. So let me
> demonstrate once more:


> $d = date_create( "2012-09-03 09:13:52" );
> var_dump( $d );
> $s = $d->format( DateTime::ISO8601 );
> $d = date_create( $s );
> var_dump( $d );
>
> Outputs:
>
> class DateTime#1 (3) {
>   public $date =>
>   string(19) "2012-09-03 09:13:52"
>   public $timezone_type =>
>   int(3)
>   public $timezone =>
>   string(13) "Europe/London"
> }
>
> class DateTime#2 (3) {
>   public $date =>
>   string(19) "2012-09-03 09:13:52"
>   public $timezone_type =>
>   int(1)
>   public $timezone =>
>   string(6) "+01:00"
> }
>
> And voila, you've just lost the timezone that belongs to the DateTime
> object.
>

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.  The DateTime object still maintains its integrity
- and includes the offset (if present).  The toString representation is not
a serialized format of every attachment of the entire object - it's a
string representation.

You actually helped prove the case for ISO-8601, IMHO.  You were able to
take the date, time and UTC offset and accomplish the same goal; all of
this from the toString format!


>
> > We have standards for a reason. I agree that changing that should not
> > be allowed. I will remove the set/get pattern functions and only print
> > a standard format. Printing an ISO standard format, which includes the
> > TZ based on UTC, or even the UTC format itself is a better solution
> > than a catchable fatal error.
>
> I disagree as it is an Ostrich Method. Instead of fixing your problem
> you'll just be hiding it.
>
> Derick
>

--bcaec54ee282d1d5b704c8cabc03--