On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye <pierre....@gmail.com> wrote:
> hi Will,
>
> On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch <wfi...@meetme.com> wrote:
> > On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue <li...@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)
> >>
> >
> > Disagree - The ISO8601 provides a good *string* representation of the
> > object. If you want every aspect of the entire object, including the
> > properties which are also objects, serialize it.
>
> 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 actually feel a static function which tracks globally would best serve
this case:
date_default_format_set('c')
This would prevent the need for setting it on a per instance basis -
similar to the way timezones can be set:
date_default_timezone_set('America/Chicago')
>
> Cheers,
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
