Hi Pierre, hi Will,
Am 03.09.2012 um 13:57 schrieb Pierre Joye pierre.php@gmail.com:
hi Will,
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)
[...]
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
returnsNULL(f.e.).
I don’t agree here, especially if we recap what the proposed purpose of the __toString() method was:
Ease debugging by allowing "echo $date;" instead of "echo $date->format(...);"
An additional constraint to make sure users use it for debugging and nothing else, would be:
Not allow changing the format, neither by ini setting or any other global means (incl. setters)
To achieve that, we need a time format that is best for debugging, meaning, as lossless as possible. While ISO8601 comes pretty close it misses out on the Olson timezone suffix. I would second the notion of creating our own format and standardizing it internally with it’s own constant and DateTime doing the right thing if passed to the constructor. Additionally to what Ryan proposed, microseconds should be part of it (which ISO allows). So, here we go:
2012-09-02T18:17:36.12345+0100 (Europe/London)
Following this, the change would be fairly easy (adding a constant, a bit parsing fu and the toString() method).
cu,
Lars