In article <200506112006.j5BK6UTH016571 / rubyforge.org>,
  noreply / rubyforge.org writes:

> Bugs item #2019, was opened at 2005-06-11 13:06
> I am pretty new to Ruby, and I could have inappropriate expectations, but I would expect that Time.parse and DateTime.parse would parse the same String in a similar fashion...most importantly, fail on the same dates.  Here is my example:
>
>
> require 'time'
> require 'date'
>
> puts Time.parse("4/12/2005")
> puts Time.parse("4/31/2005")
> puts DateTime.parse("4/12/2005")
> puts DateTime.parse("4/31/2005")
>
>
> So, there are not 31 days in April, and Time parses it fine but returns May 1.  DateTime fails on the parsing of the date.  I would have expected Time to also fail, but alas it does not.  But, to make this more confusing, Time.parse will fail on the date "4/32/2005".  So somehow there are some dates which just don't make sense at all, and some dates which "could" make sense, but may not for a certain month.
>
> Anyhow, this is rather confusing, and "non-intuitive" in my opinion.  This may be deemed as an invalid bug, but I would call the current behavior "expected".  Thanks for the consideration.

Although I'm not sure about 4/31/2005, I know an example which
Time.parse and DateTime.parse should behave differently.

% TZ=right/Asia/Tokyo ruby -rtime -rdate -e 'p Time.parse("Fri Jan  1 08:59:60 1999 JST")'
Fri Jan 01 08:59:60 JST 1999
% TZ=right/Asia/Tokyo ruby -rtime -rdate -e 'p DateTime.parse("Fri Jan  1 08:59:60 1999 JST")'
/home/akr/ruby/lib/ruby/1.9/date.rb:1168:in `civil': invalid date (ArgumentError)
        from /home/akr/ruby/lib/ruby/1.9/date.rb:1211:in `new_with_hash'
        from /home/akr/ruby/lib/ruby/1.9/date.rb:1253:in `parse'
        from -e:1

The time parsed is a leap second.  Time.parse succeeds since Time
supports leap seconds in my environment.  DateTime.parse failed since
DateTime doesn't support that.

So, it is impossible to be consistent perfectly.
-- 
Tanaka Akira