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.

I agree.

I would be mildly in favor of deprecatingall 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 adefault_datetime: datetime | None parameter, ordefault_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.

The5 looks fragile, but I don't see a good way around it, short of teachingwarnings new tricks.
Hopefully this code won't get refactored in the next few years.

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

Looks like this would be the first use ofskip_file_prefixes in the stdlib.