Re: RFC for Adding __toString to DateTime
| From: | Derick Rethans | Date: | Mon, 03 Sep 2012 08:16:14 +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 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-62710@lists.php.net to get a copy of this message | ||
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.
> 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