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
--
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
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.
$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
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
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
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
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:
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
--
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
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
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
--
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
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
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
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
16 matches
Mail list logo
