Hi All: [This was already written when Dave posted his latest comment:
>While I know that DateTime::Business stuff will eventually probably get >really complicated, I think starting off with one simple implementation >just to get the ball rolling is a good idea. If people need something >different, they'll tell us, or even better, implement it themselves. so consider this as exegesis...] 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. I've been reviewing contracts, leases, nonprofit grant agreements, and similar business documents, for date and time elements that might be abstracted for programming. I got started on this after a DT discussion months ago about 30-day business months; I went looking for legal definitions, terms of trade, standard practices, etc. One of the most ubiquitous sentences showing up is "Time is of the essence of this agreement." Economic activity is utterly embedded in time; without a time dimension, any definition of value, work, money, wealth, or exchange is incomplete, and any calculation is wrong. I mention this to suggest that there would be too many things to handle in a unified code base. Kinda like if you wanted a map showing full detail, the map would have to be as extensive as the land it portrays. I think we could hurt ourselves trying to conceive, much less design and code, a comprehensive model. So, then, what? Let's expect work to proceed in parallel: a) identify usages over time; b) abstract specific usages into models based on DT building blocks; c) develop testable code for specific usages. Identifying usages could start with just a list of goals or questions. "I want to be able to set up an accounting calendar starting at an arbitrary date." Abstracting to the existing DT code base is the part that will save time and sanity. IMO, many of the issues wracking the DT list lately spring from not fully appreciating the power of the DT capabilities already available, hence the creeping redundancy mentioned above. Thanks to Dave, Flavio, and the other ace DT programmers, there is now a set of building blocks -- date calcs, durations, recurrence sets, spans and sets of spans, calendars, etc. -- from which most applications may be readily built, albeit with a little thought and discussion. No need to get into a spot of feeling overwhelmed by the desire for completeness in business time/date usages. Let's remember the phycists' joke that time is nature's way of keeping everything from happening at once. - Bruce __bruce__van_allen__santa_cruz__ca__
