It looks like this breaks both backwards compatibility and the documented behaviour of %W and %V (“All days in a new year preceding the first Sunday are considered to be in week 0.”)

It looks like this breaks both backwards compatibility

Maybe for some interpretations of backwards compatibility, but this doesn't break any existing tests and it seems like a bug that strptime accepts some (but not all) invalid ISO weeks. I'm willing to hear counter-arguments, but it seems to me that if we consider any observable change to the behavior of a system to be backwards incompatible, we'd never be able to fix any bugs at all.

and the documented behaviour of %W and %V (“All days in a new year preceding the first Sunday are considered to be in week 0.”)

That is the documented behavior of %W and %U, not of %V. %V is documented as:

ISO 8601 week as a decimal number with Monday as the first day of the week. Week 01 is the week containing Jan 4.

This should be consistent with fromisocalendar, since fromisocalendar has the same definition.

if we consider any observable change to the behavior of a system to be backwards incompatible, we'd never be able to fix any bugs at all.

For fixing bugs that need a backwards compatibility break, we have the deprecation process.

Here, given that week 0 is a documented extension to the ISO week numbers, rejecting 2021-53 doesn't seem very clear-cut to me. I don't think many users actually read the standard when they use strptime.

That is the documented behavior of %W and %U, not of %V

Yes, sorry.

I'm sorry, can you clarify what you think this breaks? This PR does not affect the handling of week 0. This is the current behavior:

>>> datetime.strptime("2019-01-1", "%G-%V-%u")
datetime.datetime(2018, 12, 31, 0, 0)

>>> datetime.strptime("2019-00-1", "%G-%V-%u")
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
...
ValueError: time data '2019-00-1' does not match format '%G-%V-%u'

>>> datetime.strptime("2019-54-1", "%G-%V-%u")
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
ValueError: time data '2019-54-1' does not match format '%G-%V-%u'

What has changed is that %G-%V-%u no longer accepts 2021-53-1 because week 53 is not a valid ISO week. It's like if %Y-%m-%d were accepting 2023-02-29 and parsing it as 2023-03-01 with no documentation of this behavior (or in fact documentation that the string is expected to be a valid date) and no tests for it.

I don't plan to backport this to 3.11, but I think that this can very reasonably be considered a bug fix. I think you may be thinking of %U and %W as having some bearing on ISO weeks, but that is a totally different system of counting weeks, and this PR doesn't affect them.

+1 for me on the fix itself. I think it can be considered a bugfix, but I also think it has a fair chance of breaking user code. Unless it's a lot of trouble, I'd probably keep the old logic with a DeprecationWarning on the cases that are now invalid, assuming this doesn't change the interpretation of any other values, per Paul's last comment.

No worries! I think I am going to skip the DeprecationWarning thing, since that seems like it would be... complicated, and I think this will only affect a narrow range of edge cases anyway (not even sure what would generate dates like this).