This comment seems to indicate that %c might break if we don't allow for a space before a single digit, so I think we actually want (?P<d>\d{2}| {0,1}\d)" or (?P<d>\d{1,2}| \d).

That said, datetime.strptime(datetime(2021, 1, 1).strftime("%c"), "%c") seems to work OK with this change, so 🤷, maybe we just need to remove this comment? Chesterton's Fence indicates that we should probably try and figure out whether something has changed between when this comment was written and now.

A few things about these tests:

1. I realize that the rest of this module uses this same style of "a bunch of asserts in a single file", but I think most of them were added before subTest was added to the standard library. I think it would be preferable to use subtests here, since failure in any one of the tests doesn't mean a prerequisite for the other tests would also fail.
2. I really prefer the context manager style of assertRaises, since I think it's much easier to read.

If it were me, I'd probably put these tests in a loop, like so:

bad_month_re = "month must be in 1..12"
bad_day_re = "day is out of range for month"

tests = [
    ("0", "%m", bad_month_re),
    ("13", "%m", bad_month_re),
    ("0", "%d", bad_day_re),
    ("32", "%d", bad_day_re),
]

for dt_str, fmt_str, error_re in tests:
    with self.subTest(dt_str, fmt_str):
        with self.assertRaisesRegex(error_re):
            self.theclass.strptime(dt_str, fmt_str)

The use of a for loop for parameterization is something of a personal choice, though, feel free to skip that part. I find it a bit nicer because you can easily and cleanly add cases, but every control structure in a test is a possible source of error, so it's a bit of a toss-up.

As a general rule I don't like assertRaisesRegex because I don't think the specific error message raised should be part of the public interface. That said, I don't see a better way to test this.

Can we add a comment saying something like, "These tests are regression tests to ensure we have a good error message. We do not intend to guarantee any one specific error message."

Edit: ...On second thought, this might be more of a problem than I originally thought, because this is actually simply propagating the error from the datetime.datetime constructor. This feels quite fragile in a way that I would usually not be super happy with.

I'd love any suggestions on how we can test this without relying on that particular implementation detail (I am very much open to the possibility of just not putting a test for this at all).

The idea behind the original ticket was basically, "the regex is giving a really opaque error, and if we simply rely on the datetime constructor instead, we will get a much more informative error"

but if the problem is "we're throwing an opaque error", maybe I can instead make a more useful error at the regex level.

Presumably this is already covered by another test somewhere and is not necessary here?

Definitely not required - I meant for clarity line them up in a (too low, error) - (just right, no error) - (too high, error) triplet - can remove