Zefram schreef:
> Joshua Hoblitt wrote:
> >Is all that stuff just a reinvention of the wheel?
> 
> Yes, but this time it's round.

DateTime's wheels are round as well; it's just that there's a whole lot
of machinery attached to the wheels which you may not care for. If there
is any instance where DateTime gets it wrong, please let us know. The
priorities of DT have always been 1) correctness 2) ease of use 3)
efficiency, in that order. I think.

> DateTime offers no object that represents merely an abstract date.

This is something I've been thinking about a lot. I have implemented a
number of different calendars (Julian, Gregorian/Julian combined,
Pataphysical, Hijri), and I always had to copy over the time handling
from DateTime.pm. And it would be nice to have a Pataphysical calendar
with metric time.

Last weekend I finally did something about it. I've created a new
version of DateTime, where I have split the module in DT::Date and
DT::Time. I will probably use this in the new versions of my calendar
modules, but it can serve as a replacement for DateTime itself as well.

> Additionally, for Date::JD I've never seen a CPAN module with that
> functionality at all.

I think DateTime::Format::Epoch contains most of the functionality of
your Date::JD. There are no predefined modules for CJD and DJD, but
those would be easy to write, e.g.

    my $epoch = DateTime->new( year => -4713, month => 11,
                               day => 24 );
    my $cjd = DateTime::Format::Epoch->new(
                epoch => $epoch,
                unit  => 1/86400,
                type  => 'float',
                local_epoch => 'true',
                skip_leap_seconds => 1 );

    my $date = $cjd->parse_datetime(2453934.2);

    print $date; # 2006-07-17T16:48:00

If you specify "type => 'integer'", I guess you get day numbers, similar
to your JDN, etc, but I have not tested that yet.
 
> I guess you're talking about my Time::TT and Time::TAI?  These do indeed
> convert between different realisations of TT by interpolating BIPM data.
> Quite a different subject area from what (it seems) this mailing list
> is concerned with, but a good example of why one might want to use more
> than one model of time-of-day with a calendar module.

Those modules are certainly on-topic on this mailing list, and I'm
certainly impressed with them.

When my new DateTime::Date/Time-based modules are revealed, you can use
any combination of calendar and time-of-day model. One of my motivations
in writing them was to be able to handle TAI times correctly. For my
previous attempt, see DateTime::TimeZone::TAI; which unfortunatley
cannot be made to work exactly right in all cases, because TAI is not
really a time zone.

Eugene

Reply via email to