This also updates the deprecation period for %d to the current preference in PEP-387 (5 years, since 3.13); planning to end the deprecation period for both %d and %e in 3.18.

This looks good to me. @gpshead, are you OK with it?

Including %e makes sense (an oversight from the original change).

I do not believe pushing this deprecation out to 3.18 is a great idea though... We will have people dealing with production outages on leap day yet again due to bad date parsing around 2028-02-29 if the deprecation has not already shipped in a release that has seen wide adoption before that time.

3.15 will be widely adopted by 2028-02 as it should've shipped in several major long term support os distro releases that people will actually be using by 2028.
3.16 will have some adoption (maybe enough to have forced a fix to the broader ecosystem's errant strptime calls?).
3.17 probably not in wide use.
3.18 won't yet exist.

Most things I like giving a long deprecation grace period on, this one is a ticking time bomb every 4 years that IMNSHO really does need action to be taken in a timely manner. One of the rare cases where forcing the issue is a good thing.

I'm not gonna block pushing it out, but I suggest reconsidering.

Including %e makes sense (an oversight from the original change).

It wasn't implemented at the time.

production outages on leap day

In my opinion, this really depends on what we decide to do to fix the issue. If we are going to always raise an error, that itself will cause disruption, leap day or not, so I'd be in favour of a longer deprecation period.

If we are to change the default year... I haven't considered what side effects that would have. I'd imagine there are people relying on the specific year ($1900$). It is also documented, and is not specified as an implementation detail.

3.15 will be widely adopted by 2028-02 as it should've shipped in several major long term support os distro releases that people will actually be using by 2028.

We can split the removals. Make %d fail now; deprecate %e and plan removal for 3.17.

If we are going to always raise an error, that itself will cause disruption, leap day or not, so I'd be in favour of a longer deprecation period.

The major difference is that if we always raise an error, it will show up in testing environments after a Python upgrade, giving you time to roll back.
If it only fails when the input is a leap day, and you use current date as input, your production app will go down on 2028-02-29.

If we are to change the default year... I haven't considered what side effects that would have. I'd imagine there are people relying on the specific year ( 1900 ).

Yeah, this smells too much like silently returning a wrong value to avoid an exception.

We can split the removals. Make %d fail now; deprecate %e and plan removal for 3.17.

If we are to do it, I'd rather do both at once, %e was illegitimately (i.e. after the feature freeze) added to 3.13/3.14, the first version it technically should be in and is documented in is 3.15.