On 1 February 2012 09:58, Peter Vandenabeele <[email protected]> wrote: > On Wed, Feb 1, 2012 at 10:35 AM, Colin Law <[email protected]> wrote: >> >> On 1 February 2012 09:24, sandip ransing <[email protected]> wrote: >> > Hi Peter, >> > >> > validating date against Date.strptime('DATE STRING') will surely work. >> > At controller level, i can able to do validation on date but at model >> > level >> > it goes for toss bcz value gets nil before validation(at assignment >> > level) >> >> The best thing is not to let the user enter a simple string for the >> date, but give him different fields for day, month and year and then >> combine them into a date. Allowing him to enter it as a string will >> cause problems as different users will expect different ordering of >> the date. I generally use date_select for dates as Rails will >> automatically combine the form fields for you. > > > I had experience that the typical administrative user, is _very_ fast at > typing > dates on her numeric keypad. It is really a lot easier for her to type a > requested > delivery_date as 300412 (that is delivery on 30 April 2012) even if we as > developers frown upon it. Maybe a series of 3 boxes as you suggest > may also be a good compromise.
I agree that for what one might call an 'internal' app where users know what is expected that a single box may be ok. In the case of three boxes then provided tab can be used between them this can still be quick to type. > > The protection against the problem of misinterpretation, is then to show the > fully expanded date (preferably with a local fast javascript), to verify > that the > computer interpreted the data correctly. And use localisation, where users > in > EU get dd/mm/yyyy as default setting and users in US get mm/dd/yyyy as > default input setting. The most safe way is possibly to provide a drop down select box for the month then there is no confusion, but it is slower to enter. I think date_select will provide this. Of course there is no "correct" answer to this, different applications require different solutions. 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.
