On Sat, 2 Aug 2003, Joshua Hoblitt wrote:
> > In general, I have no qualms about dependencies if they're on
> > known-to-be-good modules _and_ they provide some useful functionality. In
> > this case, it's even less of a concern since Time::HiRes is a core module.
>
> We can't import Time::HiRes's time as there is already a DateTime::time()
That's alright. I'm not that big on importing stuff.
> Index: lib/DateTime.pm
> ===================================================================
> RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/lib/DateTime.pm,v
> retrieving revision 1.232
> diff -u -r1.232 DateTime.pm
> --- lib/DateTime.pm 31 Jul 2003 23:49:41 -0000 1.232
> +++ lib/DateTime.pm 2 Aug 2003 21:40:36 -0000
> @@ -48,6 +48,7 @@
> use DateTime::LeapSecond;
> use Params::Validate qw( validate SCALAR BOOLEAN HASHREF OBJECT );
> use Time::Local ();
> +use Time::HiRes;
>
> # for some reason, overloading doesn't work unless fallback is listed
> # early.
> @@ -385,7 +386,7 @@
>
> # Because epoch may come from Time::HiRes
> my $fraction = $p{epoch} - int( $p{epoch} );
> - $args{nanosecond} = $fraction * MAX_NANOSECONDS
> + $args{nanosecond} = int( $fraction * MAX_NANOSECONDS )
> if $fraction;
What's this for? I think it was working as is.
>
> # Note, for very large negative values this may give a blatantly
> @@ -403,7 +404,7 @@
> }
>
> # use scalar time in case someone's loaded Time::Piece
> -sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
> +sub now { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
Yep, looks right
> I'm not sure exactly how to test this. Call now times several times in
> a row and make that one of the results is non-zero for nanoseconds?
Yeah, I don't know a good solid way to test this either. Maybe override
Time::HiRes::time() in the test?
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
