time.strptime without a year fails on Feb 29 with:

>>> time.strptime("Feb 29", "%b %d")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 454, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month

This is due to the use of "1900" as the default year when parsing. It would be nice to have an optional "defaults" keyword argument to the strptime function that can be used to override the defaults, thus allowing leap year dates to be parsed without specifying the date.

(Note: the code in question attempted to set the year *after* the parse so that ultimately there is a valid struct_time, but since the parse never succeeds, this can't work).

This strikes me as an implementation artifact. There is no reason for time.strptime() to validate date triplets. Applications that require valid dates can use datetime.strptime(). I suggest changing time.strptime() specification to match POSIX strptime(). My understanding is that POSIX only requires field by field range checking (%d range 01 to 31, %m range 01 to 12) and not full structure validation. This would be consistent with the way leap seconds are currently treated:

>>> time.strptime('60', '%S')[5]
60

I'm seeing this when a year *is* specified with Python 2.6 and 2.7:

import time
time.strptime("20090229T184823Z", "%Y%m%dT%H%M%SZ")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 454, in _strptime_time
    return _strptime(data_string, format)[0]
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month


import datetime
datetime.datetime.strptime("20090229T184823Z", "%Y%m%dT%H%M%SZ")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/_strptime.py", line 440, in _strptime
    datetime_date(year, 1, 1).toordinal() + 1
ValueError: day is out of range for month

I'm an idiot; nevermind my comment. The original date was bogus.

The point isn’t that time.strptime validates dates but that it uses datetime internally:

julian = datetime_date(year, month, day).toordinal() - \
                      datetime_date(year, 1, 1).toordinal() + 1

Is it worth to reimplement this functionality? It strikes easier to me to just use a different year if year is undefined and date == Feb 29.

I gave it a shot, doesn’t look like a hack to me, what do you think?

This is a bit of a hack, but seems to get the work done. Does anyone have any objections to committing?

Fine with me.

New changeset f2ea7505c0d7 by Antoine Pitrou in branch '3.2':
Issue bpo-14157: Fix time.strptime failing without a year on February 29th.
http://hg.python.org/cpython/rev/f2ea7505c0d7

New changeset a5a254e8a291 by Antoine Pitrou in branch 'default':
Issue bpo-14157: Fix time.strptime failing without a year on February 29th.
http://hg.python.org/cpython/rev/a5a254e8a291

New changeset 69d407b016c1 by Antoine Pitrou in branch '2.7':
Issue bpo-14157: Fix time.strptime failing without a year on February 29th.
http://hg.python.org/cpython/rev/69d407b016c1

Patch committed and pushed, thank you!

This solution has some very undesirable properties - namely that Mar 1st is now less than Feb 29th!

It seems like the correct follow up fix would be to adjust the date of the returned struct_time back to 1900. The struct_time object doesn't have the validation issue, so this works fine. This pair of fixes then nicely circumvents the intermediate datetime object's checking, while providing a consistent end result.

That's a good point, thank you. Hynek, do you want to provide a new patch?

On it.

I wonder whether it causes trouble that we return an invalid time_struct down the road?

I have added a restoration including a short explanation + a regression test.

Small adjustments to the test as discussed in IRC.

New changeset 83598eb0d761 by Antoine Pitrou in branch '3.2':
Followup to issue bpo-14157: respect the relative ordering of values produced by time.strptime().
http://hg.python.org/cpython/rev/83598eb0d761

New changeset d1c0b57aeb1b by Antoine Pitrou in branch 'default':
Followup to issue bpo-14157: respect the relative ordering of values produced by time.strptime().
http://hg.python.org/cpython/rev/d1c0b57aeb1b

New changeset cbc9dc1c977e by Antoine Pitrou in branch '2.7':
Followup to issue bpo-14157: respect the relative ordering of values produced by time.strptime().
http://hg.python.org/cpython/rev/cbc9dc1c977e

Thanks, this should be fine now.

datetime.strptime() uses the return value of _strptime() [ which returns 1900 for 29th Feb without an year ] and eventually ends up calling datetime_new()->check_date_args() [ datetimemodule.c ] with 29th Feb 1900 and eventual failure.

Should we enhance check_date_args to take a year_dont_care flag and validate the input year argument only if it is explicitly passed?

Opened bpo-26460 for fixing the leap day bug in datetime.datetime.strptime()

I wonder whether it causes trouble that we return an invalid time_struct down the road?

turns out the answer is yes. #70647 =)