So I just scaffolded, tested and successfully reproduced your problem exactly. Playing around in the console gave some interesting results:
>> Activity.new 'activity_start_time(1i)' => '2010', 'activity_start_time(22i)' >> => '11', 'activity_start_time(100i)' => '7' >> ... activity_start_time: "2010-07-11 00:00:00" So for multiparameter attribute assignment, it just sorts the index number alphabetically and uses the data fields to assign to the object, in order (at least for Time / DateTime objects and likely for Date objects as well). It then appears to begin assigning the data to the fields, starting with the "first" field (year) and moving on, ignoring the actual numeric value of the "index" (such as my 100 above which results in its value becoming the month). So, with the rails helper defaults of '4i' and '5i', the 5 becomes the 'month' and '00' is an invalid month number. So, this would appear to be a weakness/bug in rails from my perspective. I'd think it should actually strip off the data-type character (the 'i' chars in this case) and cast the remaining 'index' characters to a Fixnum (again, at least for date/time types, not sure about aggregates/others) at which point it should respect the number as an offset: 1 => year, 2 => month, and so on so that this usage, as written out by the view helper, actually works as expected. Anyhow, just my two cents. To work around, I'd drop the :ignore_date options in your helpers. Then manually overwrite the YYYY-MM-DD value(s) of these two fields to a consistent default (since I'm assuming you're not using the date part anyway) so you can compare time values. Then you should file a bug report :-) -- 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.
