GH-70647: Deprecate strptime day of month parsing without a year present to avoid leap-year bugs #117107
Conversation
| year_in_format = True | ||
| case 'd': | ||
| day_of_month_in_format = True | ||
| if day_of_month_in_format and not year_in_format: |
There was a problem hiding this comment.
Strictly speaking this warns when a %d day-of-month is being parsed when there is no indicator of what the Month is (in which case the default of January presumably allows the day to go up to 31) but i presume such formats are unusual and thus rare enough to elide extra logic for and warn on those anyways. Being more pedantic would require one more bool in the conditional and the number of strptime format characters representing some form of month is large/ugly.
There was a problem hiding this comment.
I would be mildly in favor of deprecating all these ambiguous kinds of formats anyway, though I do think "add a fixed year to the string to be parsed" is an uglier hack than adding some mechanism for explicitly specifying defaults (e.g. accepting a default_datetime: datetime | None parameter, or default_kwargs={...}).
Which I suppose is my way of saying that I generally agree with this — I suspect that any format that has a year and a day-of-month without an actual month is way more likely to be due to an error than not. Preferably we'd give people a more accurate warning in that case, but for now any kind of warning to call attention to the situation should help.
|
Documentation added, but I need to reconcile this with my proposed non deprecation related wording drafted in #116179. |
To passively encourage people to include such comments in their own code when adopting this mitigation...
Lib/_strptime.py
Outdated
| To avoid trouble, add a specific year to the input & format. | ||
| See https://github.com/python/cpython/issues/70647.""", | ||
| DeprecationWarning, | ||
| stacklevel=5) |
There was a problem hiding this comment.
The 5 looks fragile, but I don't see a good way around it, short of teaching warnings new tricks.
Hopefully this code won't get refactored in the next few years.
There was a problem hiding this comment.
Oh, wow, nice job with the time machine :)
| stacklevel=5) | |
| skip_file_prefixes=(os.path.dirname(__file__),)) |
Looks like this would be the first use of skip_file_prefixes in the stdlib.
…r present to avoid leap-year bugs (pythonGH-117107)
If we don't do this now, people will still be using Python releases that don't guide code away from the bug by the time the next leap year rolls around. :)
Decision on what our actual breaking change will be has been left for later, this just starts the process to allow us to do it with a suggestion of how to always avoid such problems in code.
TODO list: