[rfc] HiRes

2003-08-02 Thread Joshua Hoblitt 
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 );

???

-J

--

Re: [rfc] HiRes

2003-08-02 Thread Rick Measham 
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

Re: [rfc] HiRes

2003-08-02 Thread Joshua Hoblitt 
 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

2003-08-02 Thread Rick Measham 
  $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

2003-08-02 Thread Dave Rolsky 
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

2003-08-02 Thread Claus Färber 
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

2003-08-02 Thread Dave Rolsky 
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

2003-08-02 Thread Joshua Hoblitt 
 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

2003-08-02 Thread Joshua Hoblitt 
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

2003-08-02 Thread Dave Rolsky 
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

2003-08-02 Thread Dave Rolsky 
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

2003-08-02 Thread Joshua Hoblitt 
 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

2003-08-02 Thread Joshua Hoblitt 
  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

2003-08-02 Thread Dave Rolsky 
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

2003-08-02 Thread Joshua Hoblitt 
  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: Re: [rfc] HiRes

2003-08-02 Thread rickmeasham 
 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