On 1/21/03 3:38 AM, H.Merijn Brand wrote: > FWIW *if* there should be a default date format for DBI, *please* make it > universal: YYYYMMDD and not MMDDYYYY or MM/DD/YYYY, because you have no idea > how much irritation this arouses in European countries.
Like I said: > On 1/20/03 11:34 AM, John Siracusa wrote: >> It would be nice if we had a "canonical" date/time representation. That's >> part of what the new DateTime modules being discussed on the >> [EMAIL PROTECTED] mailing list hope to deliver. I don't think we'll have a standardized "interchange format" for dates until/unless the new DateTime project matures. But such a thing is not required for database-independent code, provided you're not trying to move data from one database to another. All that's required by my proposal is that each DBD's formatter be able to read whatever is returned from its own parser: >> I propose that each $dbh be (optionally) parameterized with a date parser and >> formatter. >> >> * The parser must be able to parse any of the database's natively supported >> date/time formats. >> >> * The formatter must be able to take the output of the parser and return >> strings suitable for use in any of the database's natively supported >> date/time columns. Down the road, the DBDs may all choose to use the new DateTime modules, and therefore the same date internal representation. > I think it is worth the effort to start it, but for starters you could check > if we can use already installed Date:: modules like ::Parser, ::Calc, or > ::Manip That's up to each individual DBD: >> The DBD implementations must include default parsers and formatters of their >> choosing, using whatever modules (or custom C code or whatever :) they decide >> is best for their driver. -John
