Re: Re: [rfc] HiRes
> On the one hand, I agree. "HiRes" is bad, and "hires" is a bit worse. > OTOH, _so_ many people are already familiar with Time::HiRes, that having > our own variation on it may be confusing to as many people, or more, as > "hires" is. So are we back to DT::HiRes? Or just rename the constructor? I would like to see this functionality make it into the next release. -J --
Re: Re: [rfc] HiRes
> > So are we back to DT::HiRes? Or just rename the constructor? I would > > like to see this functionality make it into the next release. > > I guess sticking it in a separate module DateTime::HiRes works, since that > way we don't force people to load Time::HiRes if they don't need it. What about using 'require Time::HiRes' inside the hires constructor? My thinking is since we already have hires_epoch() in the DT namespace we might as well have hires_now() there too. -J --
Re: Re: [rfc] HiRes
On Sat, 9 Aug 2003, Joshua Hoblitt wrote: > > On the one hand, I agree. "HiRes" is bad, and "hires" is a bit worse. > > OTOH, _so_ many people are already familiar with Time::HiRes, that having > > our own variation on it may be confusing to as many people, or more, as > > "hires" is. > > So are we back to DT::HiRes? Or just rename the constructor? I would > like to see this functionality make it into the next release. I guess sticking it in a separate module DateTime::HiRes works, since that way we don't force people to load Time::HiRes if they don't need it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: Re: [rfc] HiRes
At 4:46 PM -1000 10/8/03, Joshua Hoblitt wrote: What about using 'require Time::HiRes' inside the hires constructor? My thinking is since we already have hires_epoch() in the DT namespace we might as well have hires_now() there too. Not to mention hires_local_now and hires_local_today :P -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners "Write a wise proverb and your name will live forever." -- Anonymous
Re: [rfc] HiRes
Dave Rolsky wrote: I take it back. I thought we'd have now() and hires_now(). ^ When I first read that I parsed it ala "now_hiring"... :) Matt
Re: Re: [rfc] HiRes
I'm not exactly sure how it should be documented but I took a stab at it anyways.
-J
--
--- DateTime.pm 2003-08-02 22:51:07.0 -1000
+++ doc.DateTime.pm 2003-08-03 10:21:15.0 -1000
@@ -1614,6 +1614,13 @@
This class method is equivalent to calling C with the
value returned from Perl's C function.
+=item * now_high_res( ... )
+
+Similar to C but uses C instead of Perl's C.
+The returned object will have fractional second information stored as
+nanoseconds. The sub-second precision of C is highly system
+dependant and will vary from one platform to the next.
+
=item * today( ... )
This class method is equivalent to:
--
> cvs server: Diffing .
> Index: Makefile.PL
> ===
> RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
> retrieving revision 1.29
> diff -u -r1.29 Makefile.PL
> --- Makefile.PL 13 Jun 2003 18:04:06 - 1.29
> +++ Makefile.PL 3 Aug 2003 09:12:13 -
> @@ -78,6 +78,7 @@
> 'Params::Validate' => 0.52,
> 'Test::More' => 0,
> 'Time::Local' => 1.04,
> + 'Time::HiRes' => 1.50,
> 'DateTime::LeapSecond' => 0.02,
> },
> );
> cvs server: Diffing lib
> 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 - 1.232
> +++ lib/DateTime.pm 3 Aug 2003 09:12:15 -
> @@ -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;
>
> # Note, for very large negative values this may give a blatantly
> @@ -404,6 +405,8 @@
>
> # use scalar time in case someone's loaded Time::Piece
> sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
> +
> +sub now_high_res { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
>
> sub today { shift->now(@_)->truncate( to => 'day' ) }
>
> cvs server: Diffing lib/DateTime
> cvs server: Diffing lib/DateTime/Language
> cvs server: Diffing t
> Index: t/04epoch.t
> ===
> RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/04epoch.t,v
> retrieving revision 1.16
> diff -u -r1.16 04epoch.t
> --- t/04epoch.t 13 Jun 2003 16:57:54 - 1.16
> +++ t/04epoch.t 3 Aug 2003 09:12:15 -
> @@ -2,7 +2,8 @@
>
> use strict;
>
> -use Test::More tests => 31;
> +use Test::More tests => 36;
> +use Time::HiRes;
>
> use DateTime;
>
> @@ -32,6 +33,24 @@
> is( $nowtest->hour, $nowtest2->hour, "Hour: Create without args" );
> is( $nowtest->month, $nowtest2->month, "Month : Create without args" );
> is( $nowtest->minute, $nowtest2->minute, "Minute: Create without args" );
> +}
> +
> +{
> +# these tests could break if the time changed during the next three lines
> +my $now = Time::HiRes::time;
> +my $nowtest = DateTime->now_high_res();
> +my $nowtest2 = DateTime->from_epoch( epoch => $now );
> +is( $nowtest->hour, $nowtest2->hour, "Hour: Create without args" );
> +is( $nowtest->month, $nowtest2->month, "Month : Create without args" );
> +is( $nowtest->minute, $nowtest2->minute, "Minute: Create without args" );
> +SKIP: {
> +skip "This might be crazy", 2;
> +
> +my $dur = $nowtest - $nowtest2;
> +is( $dur->seconds, 0, "Second: Create without args" );
> +ok( $dur->nanoseconds < 100_000_000, "Nanosecond: Create without args" );
> +};
> +
> }
>
> {
>
Re: [rfc] HiRes
> > What would DateTime::HiRes offer besides a hires_now() method? > > Nothing. :) > > DateTime::HiRes->now() > > reads nicely. It also doesn't load Time::HiRes unless we're actually going to use it. Which is probably most of the time. I guess we could get the same effect with require inside of DateTime::now_high_res(). -J --
Re: Re: [rfc] HiRes
> Mainly don't go with hires even though a 'famous' module already does.
Sounds reasonable to me. Here is a revised version of the patch. I made a basic
attempt at testing. The tests I think are questionable are already inside a skip
block. That way it won't break the CVS version and hopefully a few people will
comment out the skip and give it a try before the next release.
-J
--
cvs server: Diffing .
Index: Makefile.PL
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v
retrieving revision 1.29
diff -u -r1.29 Makefile.PL
--- Makefile.PL 13 Jun 2003 18:04:06 - 1.29
+++ Makefile.PL 3 Aug 2003 09:12:13 -
@@ -78,6 +78,7 @@
'Params::Validate' => 0.52,
'Test::More' => 0,
'Time::Local' => 1.04,
+ 'Time::HiRes' => 1.50,
'DateTime::LeapSecond' => 0.02,
},
);
cvs server: Diffing lib
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 - 1.232
+++ lib/DateTime.pm 3 Aug 2003 09:12:15 -
@@ -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;
# Note, for very large negative values this may give a blatantly
@@ -404,6 +405,8 @@
# use scalar time in case someone's loaded Time::Piece
sub now { shift->from_epoch( epoch => (scalar time), @_ ) }
+
+sub now_high_res { shift->from_epoch( epoch => Time::HiRes::time, @_ ) }
sub today { shift->now(@_)->truncate( to => 'day' ) }
cvs server: Diffing lib/DateTime
cvs server: Diffing lib/DateTime/Language
cvs server: Diffing t
Index: t/04epoch.t
===
RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/t/04epoch.t,v
retrieving revision 1.16
diff -u -r1.16 04epoch.t
--- t/04epoch.t 13 Jun 2003 16:57:54 - 1.16
+++ t/04epoch.t 3 Aug 2003 09:12:15 -
@@ -2,7 +2,8 @@
use strict;
-use Test::More tests => 31;
+use Test::More tests => 36;
+use Time::HiRes;
use DateTime;
@@ -32,6 +33,24 @@
is( $nowtest->hour, $nowtest2->hour, "Hour: Create without args" );
is( $nowtest->month, $nowtest2->month, "Month : Create without args" );
is( $nowtest->minute, $nowtest2->minute, "Minute: Create without args" );
+}
+
+{
+# these tests could break if the time changed during the next three lines
+my $now = Time::HiRes::time;
+my $nowtest = DateTime->now_high_res();
+my $nowtest2 = DateTime->from_epoch( epoch => $now );
+is( $nowtest->hour, $nowtest2->hour, "Hour: Create without args" );
+is( $nowtest->month, $nowtest2->month, "Month : Create without args" );
+is( $nowtest->minute, $nowtest2->minute, "Minute: Create without args" );
+SKIP: {
+skip "This might be crazy", 2;
+
+my $dur = $nowtest - $nowtest2;
+is( $dur->seconds, 0, "Second: Create without args" );
+ok( $dur->nanoseconds < 100_000_000, "Nanosecond: Create without args" );
+};
+
}
{
Re: Re: [rfc] HiRes
> Dave Rolsky <[EMAIL PROTECTED]> wrote: > I take it back. I thought we'd have now() and hires_now(). I think > having nanosecond at 0 makes sense to most people. Hang on, before we go any further and before code exists can I point out that we should have high_res_now() or now_high_res() or now(high_res=>1) rather than 'hires' which looks like the past tense of the verb to 'hire'. At all other times in DateTime we've made sure not to abbreviate, but high_resolution_now() is too cumbersome :) Mainly don't go with hires even though a 'famous' module already does. Cheers! Rick
Re: [rfc] HiRes
> > The more I think about this the more I like it. We'll only have to > > commit the fractional seconds fix to DateTime.pm. I'd suggest > > DateTime::HiRes.pm to be included with the DT distribution. The down > > side is this functionality wouldn't be available to decorators unless > > DateTime::HiRes was a subclass of DT. > > What would DateTime::HiRes offer besides a hires_now() method? Nothing. :) DateTime::HiRes->now() reads nicely. -J --
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote: > > > I take it back. I thought we'd have now() and hires_now(). I think > > > having nanosecond at 0 makes sense to most people. > > > > We have an awful lot of constructors already. Maybe we should put this into > > another package? > > The more I think about this the more I like it. We'll only have to > commit the fractional seconds fix to DateTime.pm. I'd suggest > DateTime::HiRes.pm to be included with the DT distribution. The down > side is this functionality wouldn't be available to decorators unless > DateTime::HiRes was a subclass of DT. What would DateTime::HiRes offer besides a hires_now() method? -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
> > # 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.
Otherwise you will most likely get a fractional result.
> >
> > # 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
The comment should be removed too.
> > 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?
We could try it. Will that confuse AUTOLOAD?
-J
--
Re: [rfc] HiRes
> > I take it back. I thought we'd have now() and hires_now(). I think > > having nanosecond at 0 makes sense to most people. > > We have an awful lot of constructors already. Maybe we should put this into another > package? The more I think about this the more I like it. We'll only have to commit the fractional seconds fix to DateTime.pm. I'd suggest DateTime::HiRes.pm to be included with the DT distribution. The down side is this functionality wouldn't be available to decorators unless DateTime::HiRes was a subclass of DT. -J --
Re: [rfc] HiRes
> I take it back. I thought we'd have now() and hires_now(). I think > having nanosecond at 0 makes sense to most people. We have an awful lot of constructors already. Maybe we should put this into another package? -J --
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Dave Rolsky wrote:
> > # 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 take it back. I thought we'd have now() and hires_now(). I think
having nanosecond at 0 makes sense to most people.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: [rfc] HiRes
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 - 1.232
> +++ lib/DateTime.pm 2 Aug 2003 21:40:36 -
> @@ -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
===*/
Re: [rfc] HiRes
I'm not really awake yet. I meant to say: I'm not sure exactly how to test this. Call now several times and make sure that one of the results is non-zero for nanoseconds? -J --
Re: [rfc] HiRes
> 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()
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 - 1.232
+++ lib/DateTime.pm 2 Aug 2003 21:40:36 -
@@ -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;
# 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, @_ ) }
sub today { shift->now(@_)->truncate( to => 'day' ) }
--
#!/usr/bin/env perl
use strict;
use DateTime;
my $dt = DateTime->now;
print $dt->datetime, "\n";
print $dt->nanosecond, "\n";
--
2003-08-02T21:43:20
4058957
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?
-J
--
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Claus Färber wrote: > Joshua Hoblitt <[EMAIL PROTECTED]> schrieb/wrote: > >> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call > >> would work without adding HiRes as a dependency. > > > It does - ... > > IMO no DateTime::* module should depend on Time or Date modules outside > of that namespace. DT should replace them eventually. > > Maybe DateTime::Hires as a replacement for Time::HiRes? Um, what would it do differently? Are you really proposing to implement the same functionality as Time::HiRes in a new namespace? That just seems silly. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
Joshua Hoblitt <[EMAIL PROTECTED]> schrieb/wrote: >> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call >> would work without adding HiRes as a dependency. > It does - ... IMO no DateTime::* module should depend on Time or Date modules outside of that namespace. DT should replace them eventually. Maybe DateTime::Hires as a replacement for Time::HiRes? Claus -- http://www.faerber.muc.de
Re: [rfc] HiRes
On Sat, 2 Aug 2003, Joshua Hoblitt wrote: > > $dt = DateTime->now_high_res(); > > or > > $dt = DateTime->now( high_res=>1 ); > > Thats a possibility too. Although to me that syntax would seem to > guarantee HiRes support to be available. I don't know if we want add > Time::HiRes as a dependency. 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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [rfc] HiRes
> OTOH, maybe I dont understand how your DateTime->hires( 1 ) call > would work without adding HiRes as a dependency. It does - but it could be more of a please use it if you've got it. Having an explicit constructor for the hires behavior says that your guaranteed to get it (IMHO). Maybe your suggestion of using it by default if it's installed is better. -J --
Re: [rfc] HiRes
> $dt = DateTime->now_high_res(); or $dt = DateTime->now( high_res=>1 ); Thats a possibility too. Although to me that syntax would seem to guarantee HiRes support to be available. I don't know if we want add Time::HiRes as a dependency. Yup, it does have that effect and I'd prefer not to have extra dependencies. How about just using it if the user has it installed? So if I don't have it, I get 20:31:59 and if I do have it I get 20:31:59.2334987324 in the call to now(high_res=>1). (of course we should probably thow a warn if its not installed and its called) OTOH, maybe I dont understand how your DateTime->hires( 1 ) call would work without adding HiRes as a dependency. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners "Write a wise proverb and your name will live forever." -- Anonymous
Re: [rfc] HiRes
> $dt = DateTime->now_high_res(); > or > $dt = DateTime->now( high_res=>1 ); Thats a possibility too. Although to me that syntax would seem to guarantee HiRes support to be available. I don't know if we want add Time::HiRes as a dependency. -J --
Re: [rfc] HiRes
At 11:42 PM -1000 1/8/03, Joshua Hoblitt wrote:
> Alternatively you could just test for it in places where it would be
useful (which are ...?):
if ($INC{'Time/HiRes.pm'}) {
# Work in HiRes
}
The only place it matters inside DT (from_epoch) already supports it.
This means that if the user has loaded Time::HiRes, then we can use
it. Otherwise we dont.
That doesn't make it very easy to say "I want an object that
represents the time 'right now' with sub second resolution".
What I'm proposing is like the Net::Ping syntax but at the class level.
So you're only suggesting it as a part of the now() call? If that's
the case why not have:
$dt = DateTime->now();
and
$dt = DateTime->now_high_res();
or
$dt = DateTime->now( high_res=>1 );
Cheers!
Rick
--
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
"Write a wise proverb and your name will live forever."
-- Anonymous
Re: [rfc] HiRes
> Alternatively you could just test for it in places where it would be
> useful (which are ...?):
>
> if ($INC{'Time/HiRes.pm'}) {
> # Work in HiRes
> }
The only place it matters inside DT (from_epoch) already supports it.
> This means that if the user has loaded Time::HiRes, then we can use
> it. Otherwise we dont.
That doesn't make it very easy to say "I want an object that represents the time
'right now' with sub second resolution".
What I'm proposing is like the Net::Ping syntax but at the class level.
# High precision syntax (requires Time::HiRes)
$p = Net::Ping->new();
$p->hires();
--
DateTime->hires( 1 );
my $dt = DateTime->now;
-J
--
Re: [rfc] HiRes
At 11:12 PM -1000 1/8/03, Joshua Hoblitt wrote:
Since from_epoch() already supports Time::HiRes I was thinking that
a class method to set use of this would be handy.
Something like:
DateTime->hires( 1 );
Alternatively you could just test for it in places where it would be
useful (which are ...?):
if ($INC{'Time/HiRes.pm'}) {
# Work in HiRes
}
This means that if the user has loaded Time::HiRes, then we can use
it. Otherwise we dont.
Just a thought.
Cheers!
Rick
--
There are 10 kinds of people:
those that understand binary, and those that don't.
The day Microsoft makes something that doesn't suck
is the day they start selling vacuum cleaners
"Write a wise proverb and your name will live forever."
-- Anonymous
