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 comparison used to be done
without a reference time).
Miscalculation of when we're in a leap minute.
Andrew
--- lib/DateTime.pm.orig2004-01-07 17:39:02.0 -0500
+++ lib/DateTime.pm 2004-02-09 22:19:24.0 -0500
@@ -908,7 +908,7 @@
{
my ( $utc_rd_days, $utc_rd_secs ) = $smaller->utc_rd_values;
-if ( $u
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&
On Sat, Feb 21, 2004 at 03:42:40PM -0600, Dave Rolsky wrote:
> I think the problem is that Data::Dumper has historically had two
> orthogonal uses. One was serializing data structures for persistence, ala
> Storable, and the other was for debugging.
>
> Nowadays, I'm guessing most people use Stor
On Wed, Mar 03, 2004 at 10:45:57AM -0300, Flavio S. Glock wrote:
> * iterate
>
> This method apply a callback subroutine to all spans of a spanset.
>
> The callback parameter is a DateTime::Span.
>
> sub callback {
> $_[0]->set_time_zone( $tz );
> }
>
> #
On Thu, Mar 04, 2004 at 04:05:21AM +, [EMAIL PROTECTED] wrote:
> Andrew Pimlott wrote:
> > $set->iterate( sub { myfunc($_); 1 } );
>
> The result would be: $set = [ 1 ]
> because that's the _only_ returned value.
Boy, that's confusing to me. I didn'
On Thu, Mar 04, 2004 at 11:28:20AM -0600, Dave Rolsky wrote:
> Actually, this doesn't encourage it and we _still_ need iterate() for
> sure. We can have set_map() only be used to create a new set, and
> iterate() only be used to alter the current set in place.
To clarify, do you mean that iterate
On Fri, Mar 05, 2004 at 02:57:57AM +, [EMAIL PROTECTED] wrote:
> This will not work. In infinite sets, the 'iterate'
> subroutine is _stored_ into the object - it is not
> executed immediately.
In retrospect, that makes sense. Then all I think you should do is
pick a different name, as you su
I noticed that DateTime::Format::Strptime defaults to returning
DateTimes in the UTC time zone. Eg,
DateTime::Format::Strptime->new(pattern => '%Y%m%d%H%M%S')
->parse_datetime('2004110200')
->time_zone->name
==> 'UTC'
This is at odds with DateTime, which defaults to f