Re: RFC for Adding __toString to DateTime
| From: | Will Fitch | Date: | Mon, 03 Sep 2012 11:54:49 +0000 |
| Subject: | Re: RFC for Adding __toString to DateTime | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-62727@lists.php.net to get a copy of this message | ||
On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey <aharvey@php.net> wrote:
> On 3 September 2012 17:36, Andrew Faulds <ajf@ajf.me> wrote:
> > Ryan McCue <lists@rotorised.com> wrote:
> >>What about ISO8601 with the Olson timezone suffixed?
> >>
> >> 2012-09-02T18:17:36+0100 (Europe/London)
> >> 2012-09-02T18:19:05+0100 (Africa/Niamey)
> >>
> >
> > Sounds good.
>
> If we're going to invent arbitrary non-standard formats, why don't we
> just tell people to use json_encode($dateTime) and be done with it?
>
> I just don't see how we can choose a sensible default format for
> users. Sometimes you want ISO 8601. Sometimes you want whatever your
> locale's customary date format is. Sometimes you want US m/d/y dates
> for interacting with legacy systems. RFC 2822. RFC 822, natch. And so
> on. I don't see why one format should be blessed over others and have
> magic behaviour when a DateTime object is cast to a string. IMO, the
> fact that users have to provide a format string and call format() is a
> good thing: explicit beats implicit, every day of the week.
>
You absolutely made the case for using DateTime::format() - which is not
the proposal here. This is for a string representation of the object via
toString.
>
> No matter what format string you use to iterate over said days.
>
> Adam
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>