Yeah of course date formats vary, it's one of the trickier issues in type adaption, can be computationally expensive, etc. A full-on date parser is probably just way out of scope for SA (the excellent dateutil package already handles it pretty well). I'm of the opinion that it would not be so horrible to restrict string-to-date conversions to the ISO format, else fail.
On 8/8/07, Michael Bayer < [EMAIL PROTECTED]> wrote: > > this particular feature is easily implemented right now as an end user > recipe, using TypeDecorator. no new type system is needed for this one > (although there is a ticket for such). > the advantage to TypeDecorator is that you get to define what kind of date > representation you'd like to convert from/to, i.e. a particular string > representation, mxDateTime, etc. that the string format of "MM/DD/YYYY > HH:MM:SS" just happened to work doesnt seem to me to be terribly useful, > considering that if you were in some other country the date would be entered > as "DD/MM/YYYY" or such. hardcoding in a "YYYY-MM-DD HH:MM:SS" format into > the code doesnt seem like such a "solution". > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
