Brett Cannon br...@python.org added the comment:
After having thought about this I have decided I am going to stick with
the current semantics. Having the year change underneath code based
solely on when it executes will cause more problems than it will solve.
--
resolution: - rejected
Changes by Brett Cannon br...@python.org:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2227
___
___
Python-bugs-list
Changes by Brett Cannon [EMAIL PROTECTED]:
--
assignee: - brett.cannon
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2227
__
___
Python-bugs-list mailing list
Miki Tebeka [EMAIL PROTECTED] added the comment:
Here is a patch, hope it'll make it to 2.6
--
keywords: +patch
nosy: +tebeka
Added file: http://bugs.python.org/file9788/_strptime.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2227
Robert Schuppenies [EMAIL PROTECTED] added the comment:
Applying the _strptime.diff patch broke the _strptime
test(test_defaults). Once you change the year, you also have to adapt
the day of week, as this becomes dynamic, too. The rest remains the
same, though. I attached a patch to this test
New submission from Gregory P. Smith:
Some common python utilities had problems on Feb 29 this year when
parsing dates using format strings that did not include a year in them.
time.strptime('Feb 29', '%b %d')
Traceback (most recent call last):
File stdin, line 1, in ?
File
Brett Cannon added the comment:
The documentation already mentions that the default values when
information left out is (1900, 1, 1, 0, 0, 0, 0, 1, -1) so the docs are
already clear. If you want to generate a patch to make the default year
be this year I would be willing to review it and
