On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote:
This means that if you do subtract_datetime on two objects you end up with
this situation:
$dur = $dt2 - $dt1
$dt1 + $dur != $dt2
$dt2 - $dur != $dt1
But honestly I don't really think that's a bug, and it's covered in the
docs.
I think that behavior would merely be a documented bug and worse a
support nightmare. I can not logically grasp how the internal between
two known fixed points on a continuing would have not have a well known
distance between them.
Won't forcing add_duation() to convert to UTC resolve this
inconsistency?
It would, but then add_duration() would produce very confusing results for
other things:
my $dt = DateTime->new( year => 2003, month => 9, time_zone =>
'America/Chicago' );
$dt->add( months => 3 );
Now what do you expect that to produce? I suspect 99% of users expect
that to produce "2003-12-01T00:00:00". In other words, we take month 9,
add 3, and get 12. The time remains untouched.
But if add_duration did the math on the UTC portions it'd give you
"2003-11-30T23:00:00".
I suspect that'd generate a much greater number of bug reports.
I think what I've come up with is the best solution. I tried to get
subtract_datetime to do the mixed local/UTC thing add_duration does, but I
could not get it to work sanely. I might take another crack at it if
others object, but I think that the current (in repo) behavior is at least
predictable, accurate, and reasonably sane (and documented).
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
