GH-70647: Include %e in deprecation of strptime() day of month parsing without a year

[StanFromIreland]

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

---

📚 Documentation preview 📚: https://cpython-previews--144570.org.readthedocs.build/

[encukou]

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?

[gpshead]

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.

[StanFromIreland]

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.