GeezerVison

time.strptime() accepts a week number (%U or %W) and a weekday that name a day after December 31. It resolves the date to the next year, but tm_yday keeps the count from the year in the input:

>>> time.strptime('2016 52 0', '%Y %W %w')[:3]
(2017, 1, 1)
>>> time.strptime('2016 52 0', '%Y %W %w').tm_yday
367
>>> time.strptime('2015 52 5', '%Y %U %w').tm_yday  # 2016-01-01
366

367 is outside the documented range, and 366 is the value for December 31. _strptime() already moves a week 0 day that falls before January 1 into the previous year. This change does the same at the other end of the year, so both calls return tm_yday=1.

Values given with %j are not changed: time.strptime('366', '%j').tm_yday is 366 today, and code can depend on that. GH-158459, which its author closed, changed that case too. I can add it if you want it.

Tested on Linux (WSL Ubuntu, gcc 15) with main at 0ada998. ./python -m test test_strptime test_time test_datetime passes. Without the change to Lib/_strptime.py, the new test_last_week fails with (2019, 1, 1, 0, 0, 0, 1, 366) != (2019, 1, 1, 0, 0, 0, 1, 1). ./python -m test -j8 passes except test_ssl, which fails the same way on unmodified main in my build (no zlib module).

The change is the elif block at Lib/_strptime.py:780, next to the existing week 0 branch.

• Issue: time.strptime() with year rollover returns out-of-range tm_yday #73267