Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62736
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain meetme.com designates 74.125.149.140 as permitted sender)
MIME-Version: 1.0
Sender: wfitch@meetme.com
In-Reply-To: <BBAB1959-F79F-44CB-BA6B-8F7CEB7EE550@strojny.net>
References: <CAArmra3oN6NMn-CPn95piNQeKN1LJ7nq3baj1B0z6pCCPZX0VQ@mail.gmail.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>
	<5044715E.3050504@rotorised.com>
	<CAArmra3vLz_NhnXPzWUwgKjRSk7HifXry39_77R4Fd6FiiTamQ@mail.gmail.com>
	<CAEZPtU6BCu2oSEnSEk+RpKU0HWh9=_JyrGpg4X3PWNKZ4krf6w@mail.gmail.com>
	<BBAB1959-F79F-44CB-BA6B-8F7CEB7EE550@strojny.net>
Date: Mon, 3 Sep 2012 08:58:16 -0400
Message-ID: <CAArmra2dqz8FmMh00=bQYsRGJ+28YfORzOBe7LZe-PwruhJKig@mail.gmail.com>
To: Lars Strojny <lars@strojny.net>
Cc: Pierre Joye <pierre.php@gmail.com>, Ryan McCue <lists@rotorised.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307f346aff1c5004c8cbb1f4
Subject: Re: [PHP-DEV] RFC for Adding __toString to DateTime
From: willfitch@php.net (Will Fitch)

--20cf307f346aff1c5004c8cbb1f4
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 3, 2012 at 8:09 AM, Lars Strojny <lars@strojny.net> wrote:

> Hi Pierre, hi Will,
>
> Am 03.09.2012 um 13:57 schrieb Pierre Joye <pierre.php@gmail.com>:
>
> > hi Will,
> >
> > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch <wfitch@meetme.com> wrote:
> >> On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue <lists@rotorised.com> wrote=
:
> >>
> >>> As far as I can tell, there's no standard which uses the Olson databa=
se
> >>> to specify the timezone, so we'd have to create one.
> >>>
> >>> What about ISO8601 with the Olson timezone suffixed?
> >>>
> >>>    2012-09-02T18:17:36+0100 (Europe/London)
> >>>    2012-09-02T18:19:05+0100 (Africa/Niamey)
> >>>
> [...]
> >
> > I don't think you will ever get a consensus on that. The reason is
> > that this case falls in the same fall than the timezone itself (but
> > per instance of an object instead of globally).
> >
> > I'd to suggest to force the definition of a format using the
> > setStringFormat (or whatever will be the name of this function).
> > __toString will then fail if no format has been set, warning and
> > returns NULL (f.e.).
>
>
> I don=92t agree here, especially if we recap what the proposed purpose of
> the __toString() method was:
>
>   Ease debugging by allowing "echo $date;" instead of "echo
> $date->format(...);"
>
> An additional constraint to make sure users use it for debugging and
> nothing else, would be:
>
>   Not allow changing the format, neither by ini setting or any other
> global means (incl. setters)
>
> To achieve that, we need a time format that is best for debugging,
> meaning, as lossless as possible. While ISO8601 comes pretty close it
> misses out on the Olson timezone suffix. I would second the notion of
> creating our own format and standardizing it internally with it=92s own
> constant and DateTime doing the right thing if passed to the constructor.
> Additionally to what Ryan proposed, microseconds should be part of it
> (which ISO allows). So, here we go:
>
>   2012-09-02T18:17:36.12345+0100 (Europe/London)
>

Hi, Lars - there wouldn't be a need for the offset if the string provides
the timezone name.  Parsing this wouldn't be an issue, however, it would be
harder to sell this approach to others.


>
> Following this, the change would be fairly easy (adding a constant, a bit
> parsing fu and the toString() method).
>
> cu,
> Lars

--20cf307f346aff1c5004c8cbb1f4--