Problem
If the user has chosen an invalid date in the standard Rails date helper (i.e. 31 of February), creating a new ActiveRecord instance will lead to ActiveRecord::MultiparameterAssignmentErrors
Example: Suppose CalendarEvent model has a date field called start_date.
Running this line:
CalendarEvent.new({"start_date(1i)"=>"2007", "start_date(2i)"=>"11", "start_date(3i)"=>"31"})
will lead to this:
ActiveRecord::MultiparameterAssignmentErrors: 1 error(s) on assignment of multiparameter attributes
from /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.5/lib/active_record/base.rb:2097:in `execute_callstack_for_multiparameter_attributes'
from /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.5/lib/active_record/base.rb:2077:in `assign_multip(EUR 0.05) arameter_attributes'
from /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.5/lib/active_record/base.rb:1678:in `attributes='
from /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.5/lib/active_record/base.rb:1508:in `initialize_without_callbacks'
from /opt/local/lib/ruby/gems/1.8/gems/activerecord-1.15.5/lib/active_record/callbacks.rb:225:in `initialize'
Following the Rails way creating a new ActiveRecord instance should not raise exceptions if input data is invalid!
The cause of this behavior is the Date class throwing ArgumentError when an attempt is made to create an invalid Date. This differs from the behavior of Time which will convert November 31 to December 1.
Solution
The proposed solution is:
1) Intercept ArgumentError if the class is Date (and only Date)
2) If ArgumentError is raised, create a Time object using the same parameters
3) Convert it to Date
All that it does is making it consistent with the behavior already present in Rails , that is, with those cases when we have a Time field and invalid parameters are sent from the form to create an model instance with such a Time field, so why don't we follow the same pattern with dates?
There is already a discusion of this issue here - http://dev.rubyonrails.org/ticket/10307
