On 12 July 2011 20:58, Colin Law <[email protected]> wrote: > On 12 July 2011 19:13, Leigh Daniels <[email protected]> wrote: >> Hi Colin, Sayuj and Michael, >> >> This is a proprietary, in-house app in Rails 3.1rc4 for the U.S market and >> they hate date_select ("Date is a little hard to fill out. It is >> time-consuming to click on "January" and scroll to "June", etc. Any chance I >> could type in 6/3/11?"). >> >>>If you want to allow the user to enter dates like this you will have >>>to parse it yourself to make sure the month and day are as you want >>>them. If the site is for an international audience I suggest you use >>>separate fields for the three components as otherwise you will have no >>>end of trouble as most of the world uses day/month/year. I don't >>>understand what you mean by "it happens before the column is available >>>in the controller". The field will be passed as a string from the >>>form to the controller and should appear in params exactly as entered >>>by the user. Note also that, since you have specified a date field in >>>the database, what is stored there is not "2011-07-11" or any other >>>string, but is the date itself. >> >> Colin, you are right that params[:start_date] is exactly as entered in the >> form. >> >> What I ended up doing was handling it in the controller with: >> [JobsController] >> def create >> @job = Job.new(params[:job]) >> @job.start_date = parse_free_date(params[:job][:start_date]) > > Something like > Date.strptime( params[:job][:start_date], "%Y/%m/%d" ) [ untested ]
I meant "%m/%d/%Y" of course (I said it was untested, it still is.) Colin > should do what you want. Don't forget to catch the exception in the > case of a parse error. > > Colin > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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-talk?hl=en.
