Parse Date bug?

[Guillaume Marcais]

Parse Date returns illegal values in a date. Ex:

[gus@comp Ruby]$ ruby -v
ruby 1.8.1 (2003-12-25) [i586-linux-gnu]
[gus@comp Ruby]$ ruby -rparsedate -e 'p ParseDate.parsedate("Monday
2003")'
[nil, 20, 3, nil, nil, nil, nil, 1]
[gus@comp Ruby]$ ruby -rparsedate -e 'p ParseDate.parsedate("Monday
march 2003")'
[nil, 3, 2003, nil, nil, nil, nil, 1]
[gus@comp Ruby]$ ruby -rparsedate -e 'p ParseDate.parsedate("Monday 1st
march 2003")'
[2003, 3, 1, nil, nil, nil, nil, 1]

In the first example, the month is 20 and in the second example, the day
in the month is 2003! Ouch.

The fact that parsedate has a hard time to parse the stupid date I gave
is fine. But I rather get a nil back than an impossible value.

Guilaume.

 

[Yukihiro Matsumoto]

Hi,

In message "Parse Date bug?"

|Parse Date returns illegal values in a date. Ex:

ParseDate is easily fooled by incomplete input.

p ParseDate.parsedate("Monday 2003")
[nil, 20, 3, nil, nil, nil, nil, 1]

This case it reads Monday 20th month 3rd day.

matz.

 

[Gavin Kistner]

ParseDate is easily fooled by incomplete input.

I think the point is that it's understandable that it may be fooled.
However, once it has attempted to create the answer, it should at least
ensure that the month is valid (jan-dec, not month "20") and that the
number of days is allowed within that month in that year.

I myself am a fan of the way Javascript handles invalid dates. For example:

someDate = new Date("9/31/2003");
someDate.toString();
=> "Wed Oct 01 2003 00:00:00 GMT-0600 (MDT)"

Basically, seconds, minutes, hours, days, and months which are larger
than a legal value are modded to the valid range, and then increment the
next larger unit.

 

[Aredridel]

Yuck. IMO, standard date classes should expect valid dates to be passed.
This is something that I'd expect from something like "FuzzyDate", which has
its value. But if someone gives me an invalid date, I want an error thrown!

Sounds like a time for

Date.new

and

Date.new_with_guess

Ari