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

Re: [mplspm]: Picking up the ball

Thread Previous | Thread Next
Stephen R. Wilcoxon
January 10, 2003 09:44
Re: [mplspm]: Picking up the ball
Message ID:
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.

> -- 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.

> -- 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).

> -- Complex parsing?  "Every Tuesday in March from 3:30PM - 5:30PM"  That'd
> be cool, but not crucial.

Agreed.  That would be cool to put in the complex parsing module.

> - DateTime::Calendar - other calendars
> -- 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 

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)).

> - DateTime::Event - Rich proposed DateTime::Holiday but Abigail pointed
> out that there are plenty of events that aren't holidays, per se.
> -- DateTime::Event::Christmas
> -- DateTime::Event::Christmas::EasternOrthodox
> -- DateTime::Event::FourthofJuly - for _very_ dumb people ;)

tons of middle-eastern holidays are also calculated in some strange manner 
I've never seen explained

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

> -- 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).

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).

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