This project is archived and is in readonly mode.

#2898 ✓invalid
knewter (at gmail)

Time.parse has a ridiculous and incorrect fallback mode

Reported by knewter (at gmail) | July 10th, 2009 @ 09:52 PM | in 2.x

Time.parse("foo") yields: Fri Jul 10 15:38:38 -0500 2009

Essentially, it is ridiculous for an unparseable time to be understood, without notice, as Time.now. The method essentially says "I don't know how to answer you, but here's something clearly wrong!"

Preferred behaviour would be either to return nil or to raise an exception, in that order of preference, I believe.

At any rate, this method clearly violates the POLS.

Comments and changes to this ticket

  • knewter (at gmail)

    knewter (at gmail) July 10th, 2009 @ 09:54 PM

    holy moley I thought this was in ActiveSupport. A thousand apologies

  • randy

    randy July 10th, 2009 @ 09:55 PM

    • Tag changed from pols, time.parse to time.parse

    +1 I've been bitten by this more than once!

  • Geoff Buesing

    Geoff Buesing July 11th, 2009 @ 03:17 PM

    • State changed from “new” to “invalid”
    • Tag changed from time.parse to time.parse

    Yeah this is in Ruby core. Fortunately, this oddball behavior has been changed in the upcoming Ruby 1.9.2 release -- Time.parse will raise an ArgumentError if it can't parse a Time from a string.

    For use right now: Time.zone.parse will just return nil if it can't parse a string, if that works for your needs.

  • knewter (at gmail)

    knewter (at gmail) July 11th, 2009 @ 03:49 PM

    Thanks a lot, that's fine behavior. :)

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>

People watching this ticket

Tags

Pages