Bug #10614: strpdate and Leap Days

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin14.0]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN

[cwoodcox (Corey Woodcox)]

I'm experiencing an issue parsing dates and leap days.

When the format string includes the year, everything works as expected:

>> Date.strptime('02/29/2012', '%m/%d/%Y')
=> #<Date: 2012-02-29 ((2455987j,0s,0n),+0s,2299161j)>

Parsing a date without a year assumes this year:

>> Date.strptime('01/01', '%m/%d')
=> #<Date: 2014-01-01 ((2456659j,0s,0n),+0s,2299161j)>

Here's my issue, parsing a leap day without a year assumes I mean this year, and this year is not a leap year:

>> Date.strptime('02/29/2012', '%m/%d')
ArgumentError: invalid date

Thinking about it now, I'm not sure what the expected behavior should be. Python assumes 1900 under the same circumstances, and it doesn't throw an exception.

[sawa (Tsuyoshi Sawada)]

'02/29/2012' clearly does not match '%m/%d'. What else would you expect than an argument error?

[cwoodcox (Corey Woodcox)]

Tsuyoshi Sawada wrote:

'02/29/2012' clearly does not match '%m/%d'. What else would you expect than an argument error?

>> Date.strptime('01/01/2014', '%m/%d')
=> #<Date: 2014-01-01 ((2456659j,0s,0n),+0s,2299161j)>

It functions as expected (ignoring the year) when given a year in the input, but not the format string. The underlying issue here, I think, is that it's assuming this year when the year is not specified. This would normally be fine, except that it can cause strange behavior when parsing a date that is a leap day. If I change my system time to 2016 (which is a leap year) then this happens:

>> Time.now
=> 2016-01-01 00:00:00 -0500
>> Date.strptime('02/29/2012', '%m/%d')
=> #<Date: 2016-02-29 ((2457448j,0s,0n),+0s,2299161j)>

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed

I don't think this is a bug, the current behavior is consistent and what I would expect. It would be inconsistent to assume the current year for %m/%d format in some cases and not in others. It is better to raise an exception if that date is not valid in the current year than to pick some arbitrary year (such as 1900) and use that.