On Mon, 13 Dec 2004, Dave Rolsky wrote:
On Mon, 13 Dec 2004, Joshua Hoblitt wrote:
It looks like the normalization is hosed.
This method, for the nth time, does not convert between units which do not have a fixed conversion rate.
Whooo, I seem to have missed the bus here. Wasn't the entire point of ->in_units so people would stop bitching about the other accessors not doing what they had been trained to expect? How is ->in_units possibly useful otherwise?
I for one am getting really tired of all the complaints about DT::Duration. Why don't we just add a bunch of accessors, with really verbose names, that return deltas relative to 0000-01-01T00:00:00 and document the hell out of the fact that this is what's going on. e.g.
-- ->estimated_years ->guessed_months ->imperfect_days, ->imprecise_hours ->loose_minutes, ->rough_seconds ->surmised_nanoseconds ->uncertain_years ->unprecise_months ->unscientific_days ->approximate_hours ->relative_minutes ->seconds_relative_to_0 . . __
I'd also point out that it probably won't work well with non-integer units. I'm not sure what'll happen when you try to add 160.2 minutes to a DateTime object, but it won't be anything good, I'm sure.
<snip/>
How can that be sane? So you ask for minutes and you get fractional minutes but you ask for seconds and get zero?
Cause really it should just blow up when you give it fractional anything.
The validation spec doesn't limit the input to integers. Either the implementation or the spec needs to be fixed...
--
my %p = validate( @_,
{ years => { type => SCALAR, default => 0 },
months => { type => SCALAR, default => 0 },
weeks => { type => SCALAR, default => 0 },
days => { type => SCALAR, default => 0 },
hours => { type => SCALAR, default => 0 },
minutes => { type => SCALAR, default => 0 },
seconds => { type => SCALAR, default => 0 },
nanoseconds => { type => SCALAR, default => 0 },
end_of_month => { type => SCALAR, default => undef,
regex =>
qr/^(?:wrap|limit|preserve)$/ },
} );
--Cheers,
-J
--
