On Sat, 21 Jun 2003, Bruce Van Allen wrote: > There's been quite a bit of talk about how to handle date and time for > business & fiscal applications. I urge _not_ trying to create a > comprehensive module. > > Instead, an extensible framework, within a DT::Business or DT::Fiscal > namespace, could grow incrementally, under the discipline of avoiding > the creeping redundancy starting to infect the DT project.
Yes! I agree 110%. There's way too much discussion in this thread of all the possible possibilities, and not enough of "here's the one or two things I have to deal with." Let's worry about the latter for now. As to creeping redundancy, I don't see any big problems with that _yet_, but I am seeing a tendency on lots of people's parts here to want to over-engineer the heck out of everything. A good example was the recent discussion of custom locales, which got way too complicated _before_ any code had even been released! Working, useful code first, then fancy ultra-powerful code. I think the evolution of the DateTime.pm module is a good example. The first version did things _I_ thought were useful. It's grown since then based on feedback from others about the things they needed. For now, I see two really important areas for business that should be addressed. 1. A DT::Business::FiscalYear module, which lets you set an arbitrary date as "the first of the year", and do calculations based on that. This would probably be a simple wrapper around DateTime.pm that overrode things like day_of_year, quarter, etc. 2. A DT::Business::Calc module (bad name though) that implemented date math in terms of a DT::Business::Calendar module that defines holidays and such, so that adding 2 days skips weekend, holidays, etc. This might also require something that has been discussed before, but not implemented, which is attached arbitrary extra info to objects in sets so that we can ask if a day is a half or full work day, etc. Implementing both of those, and making sure they work together, would provide some great building blocks for additional functionality, and would satisfy a lot of people. By all means keep discussing other, more complicated or obscure problems, but please don't do only that in favor of coding ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
