On Thursday, January 16, 2003, at 11:10 AM, after considering many points, Dave Rolsky wrote:
OTOH, this might make it easier to contend with multiple (human) languages. Parsing and formatting both have to be language-aware, right? Localization might not always be optimal: a date might have to parsed from one language and formatted for another...
I'll probably just go with the very straightforward API of:
make a parsing object
tell it to parse string X and return a DateTime
make a formatting object
tell it to format a DateTime object in a specific format
This isn't particularly clever, nor is it super-convenient. But all the
clever and convenient suggestions seem to arouse more dislike from some
people, so it's easier to agree on the tried and true. It might not be
ideal for anyone, but at least people who look at the modules will not be
turned off by an API they consider to abnormal ;)
I think Dave concluded that DateTime's own methods will be restricted to a few date formats like ISO, etc., that are (mostly) universal across human languages. With parsing and formatting objects as described above, it seems like extensibility would be available for those that need it.
- Bruce
__bruce__van_allen__santa_cruz__ca__
