# RFC for Adding __toString to DateTime

- Thread: https://externals.io/message/62627
- Original archive: https://news-web.php.net/php.internals/62627
- Started by Will Fitch on 2012-09-01T10:14:43+00:00
- Messages: 61
- Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/62627.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #62627 — Will Fitch — 2012-09-01T10:14:43+00:00

URL: https://externals.io/message/62627#62627

I would like to officially introduce an RFC with a patch to implement
__toString to DateTime.  This is a commonly requested feature that goes
unanswered mostly because of the inability to agree on a default pattern.

In short, the patch uses the ISO-8601 format as the default pattern.  The
pattern may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

- Will

---

## #62628 — Andrew Faulds — 2012-09-01T10:27:51+00:00

URL: https://externals.io/message/62627#62628 · In reply to: #62627

> I would like to officially introduce an RFC with a patch to implement
> __toString to DateTime.  This is a commonly requested feature that goes
> unanswered mostly because of the inability to agree on a default pattern.
>
> In short, the patch uses the ISO-8601 format as the default pattern.  The
> pattern may be changed via setDefaultPattern and date_default_pattern_set,
> as explained in the RFC.
>
> The link to the RFC and patch are here:
> https://wiki.php.net/rfc/datetime_tostring.
>
> While I know this isn't as interesting as many of the current proposals
> going on, I'm hoping you can give this RFC a look.
>
> - Will
>
Oh, thank you Will! I saw the bug report suggesting it myself and was 
thinking of implementing it. I'm glad to see you thought the same way I 
did, and used the ISO-8601 format as the default.

+1 from me.

-- 
Andrew Faulds
http://ajf.me/

---

## #62629 — Pierre Joye — 2012-09-01T10:36:35+00:00

URL: https://externals.io/message/62627#62629 · In reply to: #62627

hi Will,


> I would like to officially introduce an RFC with a patch to implement
> __toString to DateTime.  This is a commonly requested feature that goes
> unanswered mostly because of the inability to agree on a default pattern.
>
> In short, the patch uses the ISO-8601 format as the default pattern.  The
> pattern may be changed via setDefaultPattern and date_default_pattern_set,
> as explained in the RFC.
>
> The link to the RFC and patch are here:
> https://wiki.php.net/rfc/datetime_tostring.
>
> While I know this isn't as interesting as many of the current proposals
> going on, I'm hoping you can give this RFC a look.

It would be better to name the format method setDefaultFormat instead
of setDefaultPattern, to be consistent with the rest of the API.

(not saying I like the idea or not, only a 1st comment :)

Cheers,
-- 
Pierre

@pierrejoye

---

## #62631 — Sherif Ramadan — 2012-09-01T11:31:11+00:00

URL: https://externals.io/message/62627#62631 · In reply to: #62627

> I would like to officially introduce an RFC with a patch to implement
> __toString to DateTime.  This is a commonly requested feature that goes
> unanswered mostly because of the inability to agree on a default pattern.
>
> In short, the patch uses the ISO-8601 format as the default pattern.  The
> pattern may be changed via setDefaultPattern and date_default_pattern_set,
> as explained in the RFC.
>
> The link to the RFC and patch are here:
> https://wiki.php.net/rfc/datetime_tostring.
>
> While I know this isn't as interesting as many of the current proposals
> going on, I'm hoping you can give this RFC a look.
>
> - Will

I think you should consider making the get/setDefaultPattern() methods
into a public string called $format and just put it in the constructor
with an initial value of DateTime::ISO8601

It'd be a much simple implementation and doesn't require introducing
new functions. DateTime can either throw an exception if the format is
invalid or silently fall back to the DateTime::ISO8601

No need to complicate this.

---

## #62636 — Derick Rethans — 2012-09-01T20:54:51+00:00

URL: https://externals.io/message/62627#62636 · In reply to: #62627

> I would like to officially introduce an RFC with a patch to implement
> __toString to DateTime.  This is a commonly requested feature that goes
> unanswered mostly because of the inability to agree on a default pattern.
> 
> In short, the patch uses the ISO-8601 format as the default pattern.  The
> pattern may be changed via setDefaultPattern and date_default_pattern_set,
> as explained in the RFC.

The default should most definitely not be ISO-8601 - as it's a lossy 
format.

> The link to the RFC and patch are here:
> https://wiki.php.net/rfc/datetime_tostring.

> Methods Added
>
> void DateTime::setDefaultPattern(string $pattern)
> string DateTime::getDefaultPattern(void)

This should be descriptive. You are *only* dealing with __toString here. 
Hence the method names should reflect that:

  void DateTime::setToStringFormat(string $pattern)
  string DateTime::getToStringFormat(void)

However, I still don't believe this belongs in the class at all. It is 
rather trivial to do this in userland:

class MyDateTime extends DateTime {
	static $format = "... some format...";
	function __toString() { return $this->format(DateTime::$format); }
}

There, 4 lines. And no quaralling about formats or naming.

> <?php
> $date = new DateTime('2012-09-01 02:43:00');
> print_r($date);

Should not output just:

> DateTime Object
> (
>     [date] => 2012-09-01 02:43:00
>     [timezone_type] => 3
>     [timezone] => America/Chicago
> )

But instead should always have the tostring pattern in there. 

Also, have you checked whether it shows up when you run serialize on it?

cheers,
Derick

---

## #62652 — Stas Malyshev — 2012-09-02T01:54:04+00:00

URL: https://externals.io/message/62627#62652 · In reply to: #62627

Hi!

> I would like to officially introduce an RFC with a patch to implement
> __toString to DateTime.  This is a commonly requested feature that goes
> unanswered mostly because of the inability to agree on a default pattern.

This must indicate there's actually no default pattern that is "default"
for everyone. Which suggests maybe we shouldn't have default string
conversion there?
After all, nothing prevents one from having:

class MyDateTime extends DateTime {
   public function __toString() {
	return $this->format(/* whatever my favorite format is */);
   }
}

I'm not sure introducing special state to DateTime for it is the best
way to handle it. Also, most applications would have common date format
- which means since the state is per DateTime object, they'd have to
watch that every object produced would have this property set. I think
it'd be easier to just use DateTime->format() - this way you know what
is produced and it is clear for whoever is reading the code too.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62654 — Will Fitch — 2012-09-02T03:40:44+00:00

URL: https://externals.io/message/62627#62654 · In reply to: #62629

> hi Will,
>
> 
> > […]
> date_default_pattern_set,
> > […]
>
> It would be better to name the format method setDefaultFormat instead
> of setDefaultPattern, to be consistent with the rest of the API.
>

This makes sense. I'll update.


>
> (not saying I like the idea or not, only a 1st comment :)
>
> Cheers,
> --
> Pierre
>
> @pierrejoye

---

## #62655 — Will Fitch — 2012-09-02T04:08:10+00:00

URL: https://externals.io/message/62627#62655 · In reply to: #62636

> 
>
> > […]
> date_default_pattern_set,
> > […]
>
> The default should most definitely not be ISO-8601 - as it's a lossy
> format.
>

In terms of lossy transmission/storage, what concerns in regards to the
pattern are you referring to?  ISO-8601 is only output *if* there is no
pre-set pattern provided. So in essance,


>
> > […]
>
> > […]
>
> This should be descriptive. You are *only* dealing with __toString here.
> Hence the method names should reflect that:
>
>   void DateTime::setToStringFormat(string $pattern)
>   string DateTime::getToStringFormat(void)


> However, I still don't believe this belongs in the class at all. It is
> rather trivial to do this in userland:
>
> class MyDateTime extends DateTime {
>         static $format = "... some format...";
>         function __toString() { return $this->format(DateTime::$format); }
> }
>
> There, 4 lines. And no quaralling about formats or naming.
>

I'm definitely not sold on any naming convention or format, and I don't see
any quarrelling going on.  The purpose of the RFC is to come up with a
solution and discuss implementation.   I don't expect any quarrels for
something this simple.

I would like this discussed.  This is a feature often brought up and
requested.  I understand that it may be difficult to come to a solution,
but let's try.


>
> > […]
>
> Should not output just:
>
> > […]
>
> But instead should always have the tostring pattern in there.
>

I agree and will update.


>
> Also, have you checked whether it shows up when you run serialize on it?
>

The patch I originally wrote did implement wakeup and set state.
 Unfortunately, an accidental git checkout -- in the wrong path gave me the
distinct pleasure of rewriting this.


>
> cheers,
> Derick

---

## #62656 — Will Fitch — 2012-09-02T04:14:25+00:00

URL: https://externals.io/message/62627#62656 · In reply to: #62652

On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > […]
>
> This must indicate there's actually no default pattern that is "default"
> for everyone. Which suggests maybe we shouldn't have default string
> conversion there?
> After all, nothing prevents one from having:
>
> class MyDateTime extends DateTime {
>    public function __toString() {
>         return $this->format(/* whatever my favorite format is */);
>    }
> }
>
> I'm not sure introducing special state to DateTime for it is the best
> way to handle it. Also, most applications would have common date format
> - which means since the state is per DateTime object, they'd have to
> watch that every object produced would have this property set. I think
> it'd be easier to just use DateTime->format() - this way you know what
> is produced and it is clear for whoever is reading the code too.
>

Hi, Stas.  This has been on my mind as well.  I've considered that maybe an
INI wide setting would be beneficial here.  In fact, there are many places
within applications I've worked on where the format for many DateTime
objects are the same.  What are your thoughts on that?


> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227

---

## #62661 — Lester Caine — 2012-09-02T08:54:36+00:00

URL: https://externals.io/message/62627#62661 · In reply to: #62656

Will Fitch wrote:
> > […]
> Hi, Stas.  This has been on my mind as well.  I've considered that maybe an
> INI wide setting would be beneficial here.  In fact, there are many places
> within applications I've worked on where the format for many DateTime
> objects are the same.  What are your thoughts on that?

Will - while I can understand the desire to bring datetime in line with other 
objects, the amount of trouble some of us have with trying to identify between 
American and English dates and identifying the clients correct time zone does 
make this something of a minefield. As Derick has said, ISO-8601 is not the best 
choice because of the timezone problem, and until browsers actually provide a 
correct timezone setting this is often wrong for half of the year. 'HTTP 
Cookies' does at least include timezone, but I'd not want to use that as a 
default because it's too verbose. I prefer internally to work with UTC time only 
and fix everything to that, and then display in the CLIENT's identified format, 
so a server default setting is a little pointless ... and in my book should be 
simple UTC all the time :)

-- 
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

---

## #62664 — Stas Malyshev — 2012-09-02T09:07:22+00:00

URL: https://externals.io/message/62627#62664 · In reply to: #62656

Hi!

> Hi, Stas.  This has been on my mind as well.  I've considered that maybe
> an INI wide setting would be beneficial here.  In fact, there are many
> places within applications I've worked on where the format for many
> DateTime objects are the same.  What are your thoughts on that?

I think yet another ini setting is not a good solution, ini settings are
hard to control and they are not meant to deal with application-specific
things, since they're global.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #62666 — Derick Rethans — 2012-09-02T11:33:20+00:00

URL: https://externals.io/message/62627#62666 · In reply to: #62655

> 
> 
> > […]
> 
> In terms of lossy transmission/storage, what concerns in regards to the
> pattern are you referring to?

$ php -r 'echo `date_create()`->format( DateTime::ISO8601 );'
2012-09-02T12:26:17+0100
                   ^^^^^

is the lossless bit. It tells you nothing about the timezone. This is 
why var_dump(date_create()) has:

  public $timezone => string(13) "Europe/London"
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> ISO-8601 is only output *if* there is no pre-set pattern provided. So 
> in essance,

in essance?

> > […]
> 
> 
> > […]
> 
> I'm definitely not sold on any naming convention or format, and I don't see
> any quarrelling going on.  The purpose of the RFC is to come up with a
> solution and discuss implementation.   I don't expect any quarrels for
> something this simple.

Right, it's so simple that it can be done in userland in 4 lines of 
code. I don't want to add this.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #62667 — Derick Rethans — 2012-09-02T11:35:06+00:00

URL: https://externals.io/message/62627#62667 · In reply to: #62656

> On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> 
> > […]
> 
> This has been on my mind as well.  I've considered that maybe an INI 
> wide setting would be beneficial here.

We should absolutely NOT add ini settings for this. They make things 
unportable.


> In fact, there are many places
> within applications I've worked on where the format for many DateTime
> objects are the same.  What are your thoughts on that?

Inherit it in userland!

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

---

## #62669 — Pierre Joye — 2012-09-02T12:55:38+00:00

URL: https://externals.io/message/62627#62669 · In reply to: #62667

> We should absolutely NOT add ini settings for this. They make things
> unportable.

Agreed.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

---

## #62670 — Andrew Faulds — 2012-09-02T13:10:22+00:00

URL: https://externals.io/message/62627#62670 · In reply to: #62669

> 
>
> > […]
> Agreed.
Add my name to the list. PHP's ini settings are one of its bad points, 
IMO. We don't need any more of them.

-- 
Andrew Faulds
http://ajf.me/

---

## #62671 — Benjamin Eberlei — 2012-09-02T13:40:39+00:00

URL: https://externals.io/message/62627#62671 · In reply to: #62670

I think allowing to change teh default format would be horrible. If
libraries (such as Doctrine would) use this internally, they are at the
will of users not to fiddle with this setting. Not to speak about libraries
that contradict each other.

If there was a format, it would have to be constant imho.



> 
>
> > […]
> Add my name to the list. PHP's ini settings are one of its bad points,
> IMO. We don't need any more of them.
>
>
> --
> Andrew Faulds
> http://ajf.me/

---

## #62672 — Andrew Faulds — 2012-09-02T13:50:10+00:00

URL: https://externals.io/message/62627#62672 · In reply to: #62671

> I think allowing to change teh default format would be horrible. If 
> libraries (such as Doctrine would) use this internally, they are at 
> the will of users not to fiddle with this setting. Not to speak about 
> libraries that contradict each other.
>
> If there was a format, it would have to be constant imho.
Then ISO8601, please. It's a single, unambiguous Date and Time format.

-- 
Andrew Faulds
http://ajf.me/

---

## #62673 — Lester Caine — 2012-09-02T14:06:55+00:00

URL: https://externals.io/message/62627#62673 · In reply to: #62672

Andrew Faulds wrote:
> > […]
> Then ISO8601, please. It's a single, unambiguous Date and Time format.
WRONG !!!

-- 
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

---

## #62677 — Derick Rethans — 2012-09-02T17:20:36+00:00

URL: https://externals.io/message/62627#62677 · In reply to: #62672

> 
> > […]
>
> Then ISO8601, please. It's a single, unambiguous Date and Time format.

No it's not unambigious:

$ php -r 'date_default_timezone_set("Europe/London"); echo `date_create()`->format(DateTime::ISO8601), "\n";'
2012-09-02T18:17:36+0100

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo `date_create()`->format(DateTime::ISO8601), "\n";'
2012-09-02T18:19:05+0100

vs:

$ php -r 'date_default_timezone_set("Africa/Niamey"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0100
                   ^^^^^

$ php -r 'date_default_timezone_set("Europe/London"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
2012-12-31T00:00:00+0000
                   ^^^^^

cheers,
Derick

---

## #62679 — Lester Caine — 2012-09-02T18:59:25+00:00

URL: https://externals.io/message/62627#62679 · In reply to: #62677

Derick Rethans wrote:
> > […]
> No it's not unambigious:

Derick - is this effect just due to daylight saving differences, or IS it a bit 
more complex than that?

Personally I don't want any timezone/offset displayed as I expect it to be a UTC 
time by default on the server, rather than any offset time, which is why I'm 
with you that it should only be changed via user space applications.

-- 
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

---

## #62682 — William Betts — 2012-09-02T20:31:13+00:00

URL: https://externals.io/message/62627#62682 · In reply to: #62679

> Personally I don't want any timezone/offset displayed as I expect it to be a
> UTC time by default on the server, rather than any offset time, which is why
> I'm with you that it should only be changed via user space applications.
>
>
> --
> Lester Caine - G8HFL

Personally, if I have my way I will always use UTC server side. I
think most people
would expect / want UTC time by default on the server as well. It's
been considered
best practice for years.

---

## #62683 — Andrew Faulds — 2012-09-02T20:39:05+00:00

URL: https://externals.io/message/62627#62683 · In reply to: #62677

>
> No it's not unambigious:
>
> $ php -r 'date_default_timezone_set("Europe/London"); echo `date_create()`->format(DateTime::ISO8601), "\n";'
> 2012-09-02T18:17:36+0100
>
> $ php -r 'date_default_timezone_set("Africa/Niamey"); echo `date_create()`->format(DateTime::ISO8601), "\n";'
> 2012-09-02T18:19:05+0100
>
> vs:
>
> $ php -r 'date_default_timezone_set("Africa/Niamey"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
> 2012-12-31T00:00:00+0100
>                     ^^^^^
>
> $ php -r 'date_default_timezone_set("Europe/London"); echo date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
> 2012-12-31T00:00:00+0000
>                     ^^^^^
I'm a little confused as to what is going on here, but ISO8601 has a UTC 
format, YYYY-MM-DDTHH:MM:SSZ.
> cheers,
> Derick


-- 
Andrew Faulds
http://ajf.me/

---

## #62684 — Derick Rethans — 2012-09-02T20:45:51+00:00

URL: https://externals.io/message/62627#62684 · In reply to: #62683

> 
> > […]
> I'm a little confused as to what is going on here, but ISO8601 has a UTC
> format, YYYY-MM-DDTHH:MM:SSZ.

Yes, and that format is ambigious like I just illustrated.

cheers,
Derick

---

## #62685 — Andrew Faulds — 2012-09-02T20:46:39+00:00

URL: https://externals.io/message/62627#62685 · In reply to: #62684

> Yes, and that format is ambigious like I just illustrated. cheers, Derick 

No, you just demonstrated the time offset format is ambiguous, not the 
UTC format.

-- 
Andrew Faulds
http://ajf.me/

---

## #62686 — Will Fitch — 2012-09-02T20:48:08+00:00

URL: https://externals.io/message/62627#62686 · In reply to: #62683

>
> 
> > […]
 `date_create()`->format(DateTime::ISO8601), "\n";'
> > […]
 `date_create()`->format(DateTime::ISO8601), "\n";'
> > […]
date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
> > […]
date_create("2012-12-31")->format(DateTime::ISO8601), "\n";'
> > […]
>
> I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, YYYY-MM-DDTHH:MM:SSZ.

I think the issue on most minds is the TZ aspect. I agree with the others
on using UTC. I also think ill suggest a different approach to this.

> > […]
>
>
>
> --
> Andrew Faulds
> http://ajf.me/

---

Next page: https://externals.io/message/62627.md?page=2