On Friday, January 10, 2003, at 11:37 AM, Stephen R. Wilcoxon 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".On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <[EMAIL PROTECTED]> writes:-- Provides simple date parsing ala Time::Piece->strptime. Maybe throw inSimple parsing needs to be in the base module (yyyymmdd at least). I would
the functionality provided by Date::Parse? Maybe make this a separate
module. Doesn't matter too much.
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.
Just trying to codify my idea of simple vs. complex.
The data manipulation functions need to be written in C (ala Date::Calc)That's really an implementation question, though. The interfaces can be architected first without regard to the backend implementation.
for speed. We are using Date::Calc currently because it is the only module
(of those we tested) that ran acceptably fast.
-Ken
