> > However, if DT::Duration is given 'year' units, it should not
> > automatically convert it to months, because I may want to use that
> > information in a non-gregorian context.
>
> Well, you might, but you can't ;)
I agree completely.
> Seriously, I think this idea that DateTime::Duration should work for other
> calendars is bogus, and I've said so before.
Dave++
> There's simply too many possible ways for this to break, and while it
> would be somewhat flexible, it wouldn't be flexible enough to work with
> many odd calendars (like Discordian, Aztec, etc.).
Dave++
> > That is, if you move the year/month semantics to the calendar class,
> > then DT::Duration can support (almost) any calendar.
>
> No, it can only support some fraction of calendars, those that are lunar,
> solar, or lunisolar.
Dave++
DateTime::Duration should focus the Gregorian calendar. There is no possible way to
make it sufficiently generic to support all possible calendars without giving up
functionality useful in it's intended context. The best we should do to support
alternate calendars is to implement a method that returns an absolute time interval in
calendar independent units.
There will have to be some fudging here. For example, how many days should 3 months
convert to?
--
my $dtd = DateTime::Duration->new( months => 3 );
my( $rd_days, $rd_secs, $rd_nanos ) = $dtd->rd_values;
# or for some interesting compatability...
my( $rd_days, $rd_secs, $rd_nanos ) = $dtd->utc_rd_values;
--
is $rd_days 93, 90, 87, or 84? I'd vote for 93...
For reference, this is how I handled DT::Durations in DT::C::Mayan:
--
sub add_duration {
my( $self, $duration ) = @_;
my $dt = DateTime->from_object( object => $self );
$dt->add_duration( $duration );
my $new_self = $self->from_object( object => $dt );
# if there is an alternate epoch defined don't touch it
$self->{ rd } = $new_self->{ rd };
$self->{ rd_secs } = $new_self->{ rd_secs };
return( $self );
}
--
-J
--
