This project is archived and is in readonly mode.
date_select may call TimelinessDateTime.change which doesn't exist
Reported by Martijn Vos | January 29th, 2009 @ 11:56 PM | in 2.x
For some reason, I don't quite understand why, does
<%= f.date_select :card_expires_on, :discard_day => true, :start_year => Date.today.year, :end_year => (Date.today.year+10), :add_month_numbers => true %>
result in ValidatesTimeliness::ActionView::InstanceTag::TimelinessDateTime.change being called in action_view/helpers/date_helper.rb, line 571. Apparently @datetime is a TimelinessDateTime object. Where that comes from I have no idea, but it doesn't have a change method. Wouldn't it be more robust to simply use the following?
@datetime.day = 1
Alternatively, the following would make sure that no existing code will break due to this patch:
if @datetime.respond_to?(:change)
@datetime = @datetime.change(:day => 1)
else
@datetime.day = 1
end
This is what I'm submitting in a patch.
Comments and changes to this ticket
-
-
Martijn Vos January 30th, 2009 @ 12:20 AM
This fix can also be found in http://github.com/mcv/rails/comm...
-
Geoff Buesing January 30th, 2009 @ 03:41 PM
- State changed from “new” to “invalid”
The TimelinessDateTime class isn't defined by Rails -- looks like you're using the validates_timeliness plugin:
http://github.com/adzap/validate...
This fix needs to happen in this plugin -- a simple #change method on that class would probably do the trick (for this case, at least.)
(Fyi, standard Ruby Time, Date and DateTime classes don't define #day= setter methods -- you can only set these values on object initialization.)
-
Martijn Vos January 30th, 2009 @ 04:44 PM
Even so, isn't it dangerous for Rails to blindly assume that it receives a class of a specific type when that clearly isn't automatically true? A respond_to? check seems very sensible to me.
-
Geoff Buesing January 30th, 2009 @ 10:28 PM
I don't agree. The only reason you're getting a class that doesn't respond_to #change here is because you've using a plugin that overrides the internals of Rails.
Even if we did a respond_to check in this case, what would we do when the class didn't respond_to? You're using a day= setter method, which is an implementation detail of the plugin you're using. No other Time-like classes that I know of respond_to #day=.
I suggest you submit a patch to the validates_timeliness plugin -- should be simple enough to add a #change method.
-
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
Martijn Vos