Re: RFC for Adding __toString to DateTime

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 database > >>> 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’t 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’s 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