On Thursday, January 9, 2003, at 04:35 PM, Dave Rolsky wrote:
I like the idea of a DateTime object. It's close to my own solution to marshaling date and time calcs into my applications -- my crude module creates a Calendar object with data and methods for print layouts and online presentations of calendars in arbitrary formats. It's trivially obvious what day of the month the 4th of July is on, but quick: in 2010, what day of the week will it fall on, and which weekend is it closer to so the layout can shade a long weekend?On Thu, 9 Jan 2003, Chris Josephes wrote:I suppose that's possible too. I think the one thing the [EMAIL PROTECTED]Why not just a DateTime object, like we already have a CGI object?
cabal dislikes more than a new top-level namespace, is a single-level
module name in a new top-level namespace ;)
OTOH, if the goal is to provide a comprehensive set of datetime modules,
there's an advantage to having part of the suite be _the_ DateTime module.
For Calendar layouts I've found that no one Date/Time module does everything I need, so my module has a standard set of methods that do typical calendaring calcs (about thirty for a given date, not considering clock time), plus a dispatcher that lets the specific application add its own library of calcs, maybe outputting in Spanish instead of English. The subroutines behind the method calls use whatever way I find optimal for that calc, and I swap modules in and out as I try new ones. My applications don't need to know.
A meta-method I like for some applications is one that has the calendar object run all its calcs for every date in a range, then store the results in its own persistent table (file). The module then only has to execute (and memoize) calcs for dates that fall outside the pre-calculated range. Ten years is only ~3653 records -- a teeny database. Barring world revolution, November 7, 2006, will always be a Tuesday; for some applications why calculate again every time?
Anyway, instead of my intervening module that collects the capabilities of various others into its own objects, a DateTime object created by a single module built from the base you're describing sounds good. As much as reasonable, as you suggest, it should grab good code from everywhere else, and only rely on other resources if that's truly optimal.
I can't think of anything better than 'DateTime'.
Thanks for reviving the effort, Dave. I could dedicate a few cycles to this project...
1;
- Bruce
__bruce__van_allen__santa_cruz__ca__
