On Fri, 10 Jan 2003, Ken Williams wrote: > Yeah, the base module should accept several different non-ambiguous > "canonical" formats such as the ones used in RFCs, and things like > YYYY-MM-DD HH:MM:SS. A supplementary module could handle fuzzy stuff > like "3 days ago" and "a month from tomorrow". > > Just trying to codify my idea of simple vs. complex.
That's what I was getting at when I said the base object should _probably_ implement parsing as done in Date::Parse, which handles a small subset of the possible date representations in the world. > > 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. > > That's really an implementation question, though. The interfaces can > be architected first without regard to the backend implementation. Abso-freaking-lutely. Make it work first. Make it fast second (or third). -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
