On Tue, 31 May 2005, J. Alexander Docauer wrote:
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).
Having a timezone-specific Duration object is not necessarily useful for
doing further calculations, but it is useful as output of a reporting tool
that must take DST values as input and output.
It's easy enough to do:
$dt->set_time_zone( 'floating' );
Actually, the bug I was experiencing was incorrect calculation of months
passed. I was using delta_md, which in turn calls subtract_datetime. I
suppose one could also make delta_months, but at some point it might be
easier to implement subtract_datetime_local that wraps it all up in a
Duration object.
Yeah, but then there'd need to be local versions of all the delta_*
methods.
Even after correcting the typo, I am still seeing unusual results.
Case 3: Central DST: Spring forward ***********************************
Begin: 2005-03-01T00:00:00 End: 2005-06-01T00:00:00 Delta-Months: 2
New-Begin: 2005-03-01T01:00:00 New-End: 2005-05-31T23:00:00
Case 4: Central DST: Fall back ***********************************
Begin: 2005-09-01T00:00:00 End: 2005-12-01T00:00:00 Delta-Months: 3
New-Begin: 2005-08-31T23:00:00 New-End: 2005-12-01T01:00:00
In each case, the new value is an hour off. If it worked as you say,
add_duration would only modify the underlying UTC values, and the
presentation layer would convert those back to the desired local timezone as
needed.
Yeah, that's a bug. I'll get a fix in the next release.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
