On Fri, 10 Jan 2003, Stephen R. Wilcoxon wrote: > On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <autarch@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. 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 thing. 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 object. > 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. Rule #1: THERE WILL BE NO POKING ABOUT IN OTHER OBJECT'S 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 ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/Thread Previous | Thread Next