You could argue it is a bug in the definition of the timezone, but we
don't really have any control over that, do we? It was pretty
unexpected to get an exception from this method - I certainly don't want
to have to wrap all my DateTime calls in a eval just because the
underlying framework is that unreliable. There has to be a way that the
today method can ensure it isn't doing anything insane... doesn't there?
Zefram wrote:
Shane McCarron wrote:
Wow - sounds like a bug to me. Ick.
A bug in what, though? DateTime->today is documented to behave like a
truncate-to-day operation, which implies setting to 00:00 local time.
Do you want to change the semantics of truncate? Or make ->today
cleverer? Or is ->today the wrong approach for this application?
Most timezones avoid changing offset at midnight, in order to avoid
this kind of issue. It's handy for midnight to always be well defined.
So is this a bug in Egyptian DST rules?
-zefram
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: sh...@aptest.com