On Mon, Sep 3, 2012 at 4:16 AM, Derick Rethans <der...@php.net> wrote:
> On Sun, 2 Sep 2012, Will Fitch wrote:
>
> > On Sep 2, 2012 6:08 PM, "Lester Caine" <les...@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.
>
You have an accurate representation of the ISO format - which does not
specify the string representation of a timezone, but rather the offset of
UTC. This is not lossy. The DateTime object still maintains its integrity
- and includes the offset (if present). The toString representation is not
a serialized format of every attachment of the entire object - it's a
string representation.
You actually helped prove the case for ISO-8601, IMHO. You were able to
take the date, time and UTC offset and accomplish the same goal; all of
this from the toString format!
>
> > 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
>
