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


Reply via email to