GH-70647: Deprecate strptime day of month parsing without a year present to avoid leap-year bugs

[gpshead]

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:

• add documentation changes to the PR. (beyond what gh-70647: Better promote how to safely parse yearless dates in datetime. #116179 does as that'll be backported, document the specific deprecation in this PR)

• Issue: datetime.strptime without a year fails on Feb 29 #70647

[gpshead]

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.

[encukou]

I agree.

[pganssle]

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.

[gpshead]

Documentation added, but I need to reconcile this with my proposed non deprecation related wording drafted in #116179.

[encukou]

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.

[encukou]

Oh, wow, nice job with the time machine :)

Suggested change

	stacklevel=5)
	skip_file_prefixes=(os.path.dirname(__file__),))

Looks like this would be the first use of skip_file_prefixes in the stdlib.