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
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
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 Cfrom_epoch() with the
value
I was profiling a database-backed mod_perl application recently. A
particular request was taking several seconds to complete. At first I
thought the database was the bottleneck, but the request included only
one database query, and that query completed in about 300msec when run
from a
On Sun, 3 Aug 2003, John Siracusa wrote:
CGI-new(''): 5 wallclock secs @ 1869.16/s
(5.25 usr + 0.10 sys = 5.35 CPU)
CGI's constructor really doesn't do much at all, especially if there's no
query string or form submission to handle.
Date::Simple-new('2003-01-01'): 2 wallclock secs @
