> 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?
> >
> 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?
I don't have need for a solution, but I agree with Shane's point. It
seems to me that "truncate-to-day" logically means the start of the day which,
due to DST rules, does not necessarily mean 00:00:00. The later is a fallacy
of non-DST thinking. So if the existing DST rules for a time zone define a day
as starting @ 01:00:00, shouldn't a DST intelligent framework such as DateTime
treat truncate-to-day routines accordingly?
Just my 2 cents...
B
