Bug #5988
closedTime class interprets "2012-02-30" as "2012-03-01"
Description
=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
Updated by dmarkow (Dylan Markow) over 12 years ago
=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
Updated by naruse (Yui NARUSE) over 12 years ago
- Status changed from Open to Assigned
- Assignee set to akr (Akira Tanaka)
Updated by akr (Akira Tanaka) over 12 years ago
2012/2/10 Yui NARUSE naruse@airemix.jp:
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
Updated by akr (Akira Tanaka) over 11 years ago
- Status changed from Assigned to Rejected
No reply after explanation long time.