[mplspm]: Picking up the ball
Stephen R. Wilcoxon
wilcoxon at bridge.com
Fri Jan 10 11:37:27 CST 2003
On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <autarch at urth.org> 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
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).
Minneapolis Perl Mongers mailing list
To unsubscribe, send mail to majordomo at pm.org
with "unsubscribe mpls" in the body of the message.
More information about the Mpls-pm