Project

General

Profile

Actions

Bug #10614

closed

strpdate and Leap Days

Added by cwoodcox (Corey Woodcox) over 7 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.1.5p273 (2014-11-13 revision 48405) [x86_64-darwin14.0]
[ruby-core:66930]

Description

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.

Updated by sawa (Tsuyoshi Sawada) over 7 years ago

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

Updated by cwoodcox (Corey Woodcox) over 7 years ago

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)>

Updated by jeremyevans0 (Jeremy Evans) almost 3 years ago

  • 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.

Actions

Also available in: Atom PDF