I want the overflow behavior for DT and DT::Duration objects that support scientific
time math. The second is the official unit of time in the SI system. So I'd like to
have a a class that supports 10^9 - 10^-9 seconds.
Possible names are:
DateTime::Wrapper::SI
DateTime::Wrapper::Units
Hi Rick,
Cool idea .. and I'll add DateTime::Wrapper::AllowThingsToOverflow
(or something shorter) that allows you to construct with overflowing
parameters (like 75 seconds, 124 minutes, 34 hours, 98 days and 16
months)
Are you still going to do this? I already want to subclass it for
Dave already said that he was open to adding a flag to control the
overflow behavior if anyone could provide a valid reason for needing
it.
It sounds like you have a good reason, so post it and see if he will
add the flag.
-ben
On Mon, Jun 16, 2003 at 08:43:50AM -1000, Joshua Hoblitt
On Wed, 11 Jun 2003, Dave Rolsky wrote:
On Tue, 10 Jun 2003, Joshua Hoblitt wrote:
I've started on milliseconds and microseconds support (DT::Duration to
start with). I hope nobody else has already done this.
Um, don't we already have this with nanoseconds? What are you thinking of
At 9:29 AM -1000 11/6/03, Joshua Hoblitt wrote:
I'm willing to concede that DT::Duration can be left alone but I
really think that millisecond and microsecond support would be
useful for DT. In fact I think it would be consistent with the rest
of the API as you don't have to specify a year as
At 4:36 PM -0500 11/6/03, Dave Rolsky wrote:
No, if anything, we'll can the fractional_second constructor parameter.
Nanoseconds are here to stay, because I don't want to add bigfloat to
the mix, and I want us to be accurate.
Dave, can you explain to me again why we need nanosecond (an
On Thu, 12 Jun 2003, Rick Measham wrote:
At 4:36 PM -0500 11/6/03, Dave Rolsky wrote:
No, if anything, we'll can the fractional_second constructor parameter.
Nanoseconds are here to stay, because I don't want to add bigfloat to
the mix, and I want us to be accurate.
Dave, can you explain
On Wed, 11 Jun 2003, Tim Bunce wrote:
On Wed, Jun 11, 2003 at 09:29:31AM -1000, Joshua Hoblitt wrote:
While I know that a millisecond needs to be multiplied by 10**6
to convert it nanoseconds I don't think that qualifies as common
knowledge.
Sounds like a documentation patch is needed :)
Ok - this thread has certainly caused a lot of controversy.
To comment on Rick's comments - I think that Dave made the correct decision to have
fixed precision subsecond resolution. I in no way so attempting to insinuate this
wasn't the right thing to done.
I will _NOT_ submit a patch to add
At 12:19 PM -1000 11/6/03, Joshua Hoblitt wrote:
Proposal:
A new 2nd tier namespace for wrapper classes.
DateTime::Wrap or DateTime::Wrapper
DateTime::Wrapper::SubSecond will accept parameters for resolutions
from 10 to 10^9 subseconds. With corresponding methods returning
these units.
Cool
On Wed, 11 Jun 2003, Joshua Hoblitt wrote:
DateTime::Wrapper::SubSecond will accept parameters for resolutions from
10 to 10^9 subseconds. With corresponding methods returning these
units.
This seems like overkill for something which will basically do:
my $nano = $p{micro} *
Ugh, the fractional_second parameter must go. The docs for it are all
wrong, and what it's actually doing is _really_ odd.
Sounds reasonable.
Anyway, I _really_ don't like having mututally exclusive, but overlapping,
constructor parameters. This makes for hard-to-read docs. Ideally, each
12 matches
Mail list logo
