On Mon, 9 Feb 2004, Andrew Pimlott wrote:
It seems consistent and logical to normalize nanoseconds when
multiplying durations. There is also a comment about normalization that
seems both redundant and misleading (since comparison doesn't depend on
nanoseconds being normalized; I assume
On Mon, 9 Feb 2004, Andrew Pimlott wrote:
Miscalculation of when we're in a leap minute.
Applied.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
0.36 2004-02-10
[ BACKWARDS INCOMPATIBILITY ]
- The default time zone is now the floating time zone, not the local
time zone, because we cannot determine the local time zone reliably on
all systems.
Note that we really cannot assume that using local for a time zone will
work, and so parsing
I wrote up some quick guidelines for these modules after fixing a test
failure in DateTime::Format::HTTP where it assumed that it could use
local for the time zone and have it work everywhere.
Please feel free to suggest changes to the document or supply patches.
The POD is in the repo and the
Okay, I'm probably being stupid but...how do I get the number of seconds
a DateTime::Duration takes? I *think* I should be using delta_seconds,
but that doesn't seem to work:
use DateTime::Duration;
my $dur = DateTime::Duration-new(hours = 2);
print $dur-hours . : .
$dur-minutes .
On Tue, 10 Feb 2004, Mark Fowler wrote:
Okay, I'm probably being stupid but...how do I get the number of seconds
a DateTime::Duration takes? I *think* I should be using delta_seconds,
but that doesn't seem to work:
use DateTime::Duration;
my $dur = DateTime::Duration-new(hours = 2);
On 2/10/04 12:17 PM, Dave Rolsky wrote:
I should add a section to the docs on this so that people know what to
expect.
Yes, please do, because I am eternally confused by this :)
-John
On Tue, Feb 10, 2004 at 10:01:51AM -0600, Dave Rolsky wrote:
On Mon, 9 Feb 2004, Andrew Pimlott wrote:
Although, looking at _normalize_nanoseconds and the tests for it, I
don't understand the sense of normalizing to (-1, 1) at all.
I'm not sure what you're referring to.
I don't see why
On Tue, 10 Feb 2004, Matt Sisk wrote:
I understand why you have to deal with the ambiguity, but I still really
wish there were an easer way to get a rough shot at this value when
absolute precision is not required.
In particular I run into this problem when I'm trying to generate
values, in
