This project is archived and is in readonly mode.

#1824 ✓invalid
Martijn Vos

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 =>, :end_year => (, :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? = 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 = 1

This is what I'm submitting in a patch.

Comments and changes to this ticket

  • Martijn Vos

    Martijn Vos January 30th, 2009 @ 12:16 AM

    • Tag set to select_date

    Here's the patch.

  • Martijn Vos
  • Geoff Buesing

    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:

    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

    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

    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.

  • Martijn Vos

    Martijn Vos February 1st, 2009 @ 11:57 AM

    I understand. I'll submit a patch there.

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=""></a>

People watching this ticket