Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

This project is archived and is in readonly mode.

date_select may call TimelinessDateTime.change which doesn't exist

#1824

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.

Reported by Martijn Vos · January 29th, 2009 @ 11:56 PM

State: invalid
Milestone: 2.x
Assigned to: nobody
Importance: none

Activity

  1. Martijn Vos
    Martijn Vos
    • Tag set to select_date

    Here's the patch.

    January 30th, 2009 @ 12:16 AM

  2. Martijn Vos
    Martijn Vos

    This fix can also be found in http://github.com/mcv/rails/comm...

    January 30th, 2009 @ 12:20 AM

  3. Geoff Buesing
    Geoff Buesing
    • 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.)

    January 30th, 2009 @ 03:41 PM

  4. Martijn Vos
    Martijn Vos

    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.

    January 30th, 2009 @ 04:44 PM

  5. Geoff Buesing
    Geoff Buesing

    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.

    January 30th, 2009 @ 10:28 PM

  6. Martijn Vos
    Martijn Vos

    I understand. I'll submit a patch there.

    February 1st, 2009 @ 11:57 AM