develooper Front page | perl.datetime | Postings from January 2003

Re: [mplspm]: Picking up the ball

Thread Previous | Thread Next
Dave Rolsky
January 10, 2003 10:51
Re: [mplspm]: Picking up the ball
Message ID:
On Fri, 10 Jan 2003, Stephen R. Wilcoxon wrote:

> On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <> writes:
> > -- Provides simple date parsing ala Time::Piece->strptime.  Maybe throw in
> > the functionality provided by Date::Parse?  Maybe make this a separate
> > module.  Doesn't matter too much.
> Simple parsing needs to be in the base module (yyyymmdd at least).  I would
> prefer to see complex parsing put in a different module that could be
> included (or not) based on if your application needs any complex parsing.

How much simple parsing is enough is probably debatable, but let's not
start debating it yet.  Like I said, I think support for the strptime
interface belongs in the base class.  Support for a generic "parse_this"
method that handles some subset of common formats (those handled by
Date::Parse) _probably_ belongs in the base as well.

> > -- Date calculations ala Date::Calc.  Some of what Date::Calc provides
> > doesn't really return _dates_ per se, and that can go in a separate
> > module.
> The data manipulation functions need to be written in C (ala Date::Calc)
> for speed.  We are using Date::Calc currently because it is the only module
> (of those we tested) that ran acceptably fast.

No, the data manipulation functions do not need to be written in C.

However, what would be _very_ desirable would be an implementation of the
base DateTime API in C, perhaps DateTime::Implementation::XS or some such

I'm all for fast, but I want to see a working, well-tested API before I
see a fast implementation.  It's a heck of a lot easier to implement
something in Perl and then convert bits to C as needed then it is to start
off from scratch with C.

> > -- Should be possible to plug in holiday calendars for business day
> > calculation.  See Date::Calendar in Date::Calc.
> It would be nice if we could come up with a pluggable holiday scheme (pass
> a code reference to the constructor and have it use that at a minimum).
> There are currently 3 formats (that I know of) for indicating holidays
> (depending on what module you're using) and alot of people have written
> their own already (our Date::Calc subclass uses a database table).

This will absolutely work.  You'll have a DateTime::BusinessDays::Reuters
class you use internally, and it will conform to some defined API.  You'll
then be able to tell the DateTime object to use that class when
calculating business days.

> > -- Must be interoperable with base datetime object!  This means that we
> > can convert back and forth between the two on demand.
> >
> > -- DateTime::Calendar::Chinese
> > -- DateTime::Calendar::Discordian
> DateTime::Calendar::Solar::<specific> - there are at least 2 "common" solar
> calendars

Really?  I'm so _not_ an expert on this stuff.  I'll let others take a
wack at this part.

> Ideally, it would be nice to be able to convert between all of the
> different calendars directly (ex some Asian holidays are still calculated
> based on non-Gregorian calendars (some countries have holidays calculated
> on at least 3 different calendars)).

Yes, this is a requirement.  Any DateTime::Calendar::X module _must_ be
able to accept a DateTime object given to its constructor.  And a
DateTime::Calendar::X object _must_ be able to return a standard DateTime

> Events also need to be integrated with holidays (some holidays/events
> change based upon other ones) and weekend definitions (see below).

A module that implements the BusinessDays interface (name subject to
change) will most likely make use of these other modules internally.

> > -- Should handle business versus normal days.
> This needs to be as flexible as possible.  What days constitute weekends
> varies (sometimes for days worked and sometimes only for holiday
> calculations).  What to do with holidays/events if they fall on weekends
> (or other holidays) varies (usually countries have a "move" forward/back
> rule for some holidays and a "ignore" it rule for other holidays but some
> countries vary more than that).

It can be as complex as you want.  Again, if business days are implemented
like this:

  my $next_business_day = DateTime::BusinessDays::IslamicHolidays->next_after( $datetime_object );

Then the internals of the "next_after" method can be as simple or complex
as you want, right?

I cannot stress this enough:  With a solid API, implementations can be as
fast/slow, complex/simple, clean/inscrutable as needed.  And everything
will work together, regardless of internals.


That will also be rules 2-10.

> Another thing that would be nice (not sure where it would go) would be some
> astronomical datetime conversion functions (such as converting between TD
> and UTC).  This may become critical for certain things (the only accurate
> equinox algorithm I've found calculates in TD).

I have no idea what TD is.  Presumably, a DateTime::Algorithm::Equinox
module will either implement the necessary conversion internally, or use a
DateTime::{Algorithm or Calendar}::TD module.  Not my problem, as long as
they all conform to the API ;)


House Absolute Consulting

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About