Hi Clemens Proper date/time validation needs a good parser and Ruby #parse methods don't really cut it I'm afraid hence my solution. But we can discuss that more later. Would be great to to get an accurate, customizable date/time parser in Rails.
I'm not on IRC much but happy to jump on to discuss. You are 9 hours behind me (Austria still? from github) so I will look for you at after 9am your time if you don't mind chatting during the day. Cheers, Adam On May 27, 5:40 am, Clemens Kofler <[email protected]> wrote: > Hi Adam, > > from the name I would have never guessed that your plugin does things > similar to mine! ;-) It looks pretty awesome, though. > > Maybe we should join forces on this issue? If you want to do this you > can get me in IRC - I'm usually hanging out in the Rails-Core channel > and my nick is clemensk. I'd love to discuss this with you and hear > your opinions. > > - Clemens > > On May 25, 12:48 pm, Adam Meehan <[email protected]> wrote: > > > Wondering whether my validates_timeliness plugin may give some ideas > > on the date/time parsing front. The Formats class handles I18n > > parsinghttp://github.com/adzap/validates_timeliness/blob/572d80d227f4e727350... > > > It also includes a suboptimal solution for the date ambiguities you > > mentioned. Suboptimal because its either one or the other > > interpretation for the whole app, which is not ideal. I plan to > > refactor the class to allow format filtering on the fly and also date > > disambiguation based on the locale. > > > Adam > > > On May 24, 9:28 pm, Clemens Kofler <[email protected]> wrote: > > > > 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
