Bug #5988: Time class interprets "2012-02-30" as "2012-03-01"

• Status: Rejected
• Assignee: akr (Akira Tanaka)
• Target version: -
• ruby -v: ruby 2.0.0dev (2012-02-09 trunk 34499) [x86_64-darwin11.3.0]

[dmarkow (Dylan Markow)]

=begin
The time class seems to accept any number from 1-31 as a valid day for any month of the year, even if the month has less than 31 days. If the day exceeds the number of days, it just spills over into the following month; "2012-02-30" become "2012-03-01", "2012-04-31" becomes "2012-05-01", and so on. It's not until you try 32 as a day number that you get the expected Argument Error. This happens with Time.new, Time.parse, Time.local, Time.utc, etc.

irb(main):002:0> RUBY_DESCRIPTION
=> "ruby 2.0.0dev (2012-02-09 trunk 34499) [x86_64-darwin11.3.0]"
irb(main):003:0> Time.parse "2012-02-30"
=> 2012-03-01 00:00:00 -0800
irb(main):004:0> Time.new 2012, 2, 30
=> 2012-03-01 00:00:00 -0800
irb(main):005:0> Time.local 2012, 2, 30
=> 2012-03-01 00:00:00 -0800
irb(main):006:0> Time.utc 2012, 2, 30
=> 2012-03-01 00:00:00 UTC
irb(main):007:0> Time.new 2012, 4, 31
=> 2012-05-01 00:00:00 -0700
irb(main):008:0> Time.new 2012, 2, 32
ArgumentError: argument out of range
from (irb):8:in initialize' from (irb):8:in new'
from (irb):8
from /Users/dylan/.rbenv/versions/2.0.0-dev/bin/irb:12:in `'
irb(main):009:0>

=end

[dmarkow (Dylan Markow)]

=begin
By comparison, the Date class handles this properly:

irb(main):004:0> Date.new 2012, 2, 29
=> #<Date: 2012-02-29 ((2455987j,0s,0n),+0s,2299161j)>
irb(main):005:0> Date.new 2012, 2, 30
ArgumentError: invalid date
from (irb):5:in new' from (irb):5 from /Users/dylan/.rbenv/versions/2.0.0-dev/bin/irb:12:in '
irb(main):006:0>
=end

[naruse (Yui NARUSE)]

• Status changed from Open to Assigned
• Assignee set to akr (Akira Tanaka)

[akr (Akira Tanaka)]

2012/2/10 Yui NARUSE [e-mail]:

The time class seems to accept any number from 1-31 as a valid day for any month of the year, even if the month has less than 31 days. If the day exceeds the number of days, it just spills over into the following month; "2012-02-30" become "2012-03-01", "2012-04-31" becomes "2012-05-01", and so on. It's not until you try 32 as a day number that you get the expected Argument Error. This happens with Time.new, Time.parse, Time.local, Time.utc, etc.

Once, we tried to check time validity by testing round tripness.
[ruby-core:14517]

But it was too strict. So we abondon the test.
[ruby-dev:33086]

If people really need strict Time constructors,
new methods (Time.strict_local, Time.strict_utc, etc.) should be considerd.

Tanaka Akira

[akr (Akira Tanaka)]

• Status changed from Assigned to Rejected

No reply after explanation long time.