On Fri, 31 Dec 2004, Max Campos wrote:
I think this your average newcomer will find this very confusing!
That may be true but ...
I think that a method like this should do what you expect it to do, and if it can't do that, then return an error. This is one of those cases where instead of returning an error, it returns an unexpected result. Very few
... I still think throwing some sort of error is just going too far. After all, it's perfectly reasonable to ask for units that the duration can't convert to internally, and it's not indicative of any sort of mistake on the caller's part.
Ex: - DateTime->now returns UTC
I'm not sure what would be better. We _could_ return the local time (from localtime as opposed to gmtime) and use the floating time zone, but it can't return localtime in the _local_ time zone, since we can't get the local time on all platforms.
Changing this to return local time in the floating time zone is seriously backwards-incompatible. People who've written code like this expecting UTC:
my $dt = DateTime->now( time_zone => 'America/Chicago' );
will end up with some quite different if now() returned an object in the floating time zone.
I could add a now_local (better as local_now?) constructor.
- There's no way to set a default timezone
I sort of remember some potential ways to do this being discussed on the list, but I can't find it.
- DateTime::Duration should be the so called "stopwatch duration"
Yeah, the more I think about this the more I agree, but we're kind of stuck with it now. In fact, DT::Duration is really a _delta_, and a duration would be the stopwatch duration (since a delta can be negative, but a duration cannot).
Not sure how best to handle this, but I don't think I can just break backwards compatibility at this point. Maybe in DateTime2 or for Perl6 ;) Despite the problems you mention (and others) DateTime _is_ being very widely used, from what I've heard.
-dave
/*=========================== VegGuide.Org Your guide to all that's veg. ===========================*/
