On Fri, 10 Jan 2003, Stephen R. Wilcoxon wrote:
> On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <[EMAIL PROTECTED]> 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
=======================*/
