This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients Sriram Rajagopalan, belopolsky, gregory.p.smith, nickzoic, p-ganssle, polymorphm, xtreak
Date 2020-03-02.19:37:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1583177837.68.0.139396504237.issue26460@roundup.psfhosted.org>
In-reply-to
Content
I don't think adding a default_year parameter is the right solution here.

The actual problem is that `time.strptime`, and by extension `datetime.strptime` has a strange and confusing interface. What should happen is either that `year` is set to None or some other marker of a missing value or datetime.strptime should raise an exception when it's being asked to construct something that does not contain a year.

Since there is no concept of a partial datetime, I think our best option would be to throw an exception, except that this has been baked into the library for ages and would start to throw exceptions even when the person has correctly handled the Feb 29th case.

I think one possible "solution" to this would be to raise a warning any time someone tries to use `datetime.strptime` without requesting a year to warn them that the thing they're doing only exists for backwards compatibility reasons. We could possibly eventually make that an exception, but I'm not sure it's totally worth a break in backwards compatibility when a warning should put people on notice.
History
Date User Action Args
2020-03-02 19:37:17p-gansslesetrecipients: + p-ganssle, gregory.p.smith, belopolsky, polymorphm, Sriram Rajagopalan, xtreak, nickzoic
2020-03-02 19:37:17p-gansslesetmessageid: <1583177837.68.0.139396504237.issue26460@roundup.psfhosted.org>
2020-03-02 19:37:17p-gansslelinkissue26460 messages
2020-03-02 19:37:17p-gansslecreate