On Tue, 31 May 2005, J. Alexander Docauer wrote:
In my program, I need to know the difference between two dates in
time-of-day-independent days/months, but also do DST-dependent calculations.
However, after this change, subtracting DST DateTime objects whose difference
crosses the spring DST change causes a day to be dropped from the resulting
Duration object. The number of days between two dates (at midnight) should
be independent of whether the calculation is being done on DST dates. The
documentation for DateTime notes that there is no constant conversion between
hours and days, I would assume for this very reason.
The motivation for this change seems to be to have subtract_datetime return a
Duration that is the difference of the UTC equivalents of the given (possibly
local) DateTime objects. While I can see the utility of wanting to know the
UTC time difference, this method is documented as not returning any sort of
absolute time difference. The resulting Duration object is only useful in
relation to the DateTime objects that created it. Therefore, it would seem
reasonable that the duration would be defined in terms of the timezone that
created it.
Well, when you want to know how far apart two datetimes are in duration,
you'd always do that based on UTC. UTC is the "real" datetime, and the
time zone adjusted datetime is just for presentation.
In other words, the duration is the actual number of hours that passed,
aka the floating point number of rotations of the earth on its axis that
have occurred. If it were to measure the difference based on non-UTC
datetimes, the results would not have any correspondence to the real
universe (at least sometimes).
If you just want to know how many days have passed, that's what the
delta_days method is for.
I am further confused by this change because it does not update the behavior
of associated methods such as add_duration. In fact, adding the result of
subtract_datetime to the subtrahend using add_duration returns a value that
is different from the original minuend of subtract_datetime. Whatever the
intended behavior of these methods, it is not consistent.
It would seem to me that if this really is the desired behavior of
subtract_datetime, there should be two sets of methods, one for doing
calculations relative to the current timezone and one that always produces
durations relative to UTC equivalents (using the suffixes *_utc or *_local
to distinguish them).
Applying the inverse diff of this change causes my program to appear to work
normally again.
The attached script demonstrates the described behavior.
Can you tell me what output you expect to get from this script? AFAICT,
the output it gives makes sense but I think you have a bug in the
orthogonal method where you add the duration to $end instead of $begin
(line 20). If I fix that then the two begin/end times are always the
same, which according to the comment in your code is what you would expect
to happen.
If you add 3 months to a given datetime, I would _not_ expect the time
portion to ever change. So the adding definitely seems right. Adding is
done only on the units specified. If you only add months, that's all
that's affected. Basically it breaks it up into individual units, does
the addition, and then reassembles the units into a datetime at the end.
The change you're referencing was done based on someone else's bug report,
so it's not clear to me how to reconcile the two.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
