This is still only at the idea/design stage.  It's originally
registered as an idea owned by Tim Bunce, but he doesn't have time
dealing with it.

The big question - do I have time dealing with it?  Maybe.  I hope I
can get the basic functionallity I need myself ... later in March.
I don't have the time implementing anything at the moment as I have to
catch a plane... :)


My main mission with this module is to approach dates and timestamps
in an object oriented way.  Tons of functionality and features should
be available by object methods.  Still it should be a fairly
lightweight module.  Of course the OO approach will always lead to
some overheads, but it shouldn't do things that aren't needed - like
converting from one format to another - before it's really needed.

When searching at CPAN, there is a myriad of different packages
dealing with date and time troubles.  I don't want to reinvent the
wheel.  Actually I hate Gregorian dates as much as date parsing in
general, so I will let others deal with that - as far as possible.
All I want to do here is to do a little bit of researching into the
jungle of existing packages, see whitch modules provides what
functionalities, and make this functionallity available in an object
oriented way - because as far as I can see, there are no object
oriented packages for date handling out there (with some exception -
but those are specialized packages).  I want to bring a bit order into
all the mess about dates and times.  Anyway, I'm short on time now, so
for now I will only lean on Date::Manip.  According to the Date::Manip
pod, the biggest disadvantage with it is that it's slow.  I will
gladly accept patches witch might speed up this package.

My idea is that this class might be subclassed into different date
representations.  One object can store the data to several subclasses,
and as long as the data is available, converting from one type to
another should be handled almost costlessly by an AUTOLOAD that does
nothing else than a blessing.  I'll tell more detailed about my
thoughts later.

I will mainly concentrate on the most trivial subclass;
Date::Time::UnixTime.  This format is mostly beeing criticized for not
beeing able to handle historical dates, nor microprecision.  Well,
since we have no explicit typing in Perl, it's trivial to extend it
all possible ways - you can have negative numbers, 64 bit should be
enough for a span of ~554 gigayears, you can use floating point for
finer precisions ... etc.  Well, I guess it's all implemented as
decimal numbers using string processing in perl.  I think that sucks a
bit, but ... hey, it works.

So Date::Time::UnixTime is universal.  All methods should be
implemented for this subclass, and all subclasses of Date::Time should
support some methods for importing/exporting to this format.  The
Date::Time AUTOLOAD will then ensure that misc methods like
$datetime->strftime("..."), $datetime->cmp($datetime), etc, will
always work regardless of the original representation.  Again, I will
tell more detailed about those thoughts later.

Date::Time should support absolute dates as well as relative times,
and all possible calendar and time systems that anyone cares to