I'd love to have Date/Time parsing as well but I'm not sure the solution I have right now is really fit for production. As far as I see it, the only way to rely on output formats, turn them into regular expressions and then parse them accordingly (I just pushed an update to my plugin where I switched to DateTime#strptime for parsing - works like a charm).
There are different approaches to parsing (Unicode suggests using "lenient parsing") but in the end you always kind of depend on the user: AFAIK, 02/03/04 as an English date could mean 2nd February 04, 3rd April 02 and 4th March 03, right? The only dates that are fairly unambiguous are dates including month names and 4-digit years. So how do I circumvent this issue when trying to parse? Question is: What would/should happen if the user passes a date/time that can't be parsed? Raise errors? Just set it to nil? - Clemens On May 23, 2:33 pm, Michael Koziarski <mich...@koziarski.com> wrote: > > Any opinions on that? I can submit a patch with tests at any time. > > I'd be hesitant to add just number support when date functionality is > also pretty important. Would it take much more effort to do it for > numbers and dates / times? Shipping half a feature can be more > frustrating than not shipping any localised input at all. > > Your plan for having an AR option to do this conversion sounds like a > good way to wire it up. > > -- > Cheers, > > Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
