email.utils.parsedate_tz misinterprets obsolete RFC 2822 three-digit years

[augusto-rehfeldt]

Bug report

Bug description:

Documented behaviour: The email.utils documentation describes parsedate_tz as performing “the same function as parsedate()” with an additional timezone element. The parsedate() documentation says: “Attempts to parse a date according to the rules in RFC 2822.” RFC 2822 §4.3 specifies: “If a three digit year is encountered, the year is interpreted by adding 1900 to the year.”

Expected: A non-None tuple with year component 2000.

Actual: (100, 1, 1, 12, 0, 0, 0, 1, -1, 0)

import email.utils
import re

s = '01 Jan ' + str(100) + ' 12:00:00 +0000'
if not re.fullmatch(r'01 Jan [1-9][0-9]{2} 12:00:00 \+0000', s):
    print('REFUTATION REJECTED: input is not a valid obsolete RFC 2822 date')
else:
    expected = int(s.split()[2]) + 1900  # RFC 2822 §4.3
    actual = email.utils.parsedate_tz(s)
    if actual is None or actual[0] != expected:
        print('REFUTATION CONFIRMED:', repr(s), 'actual=', actual,
              'expected_year=', expected)
    else:
        print('REFUTATION REJECTED: actual year matches RFC 2822 §4.3')

Output on Python 3.14.6 (Windows-11-10.0.26220-SP0), standard library email.utils:

REFUTATION CONFIRMED: '01 Jan 100 12:00:00 +0000' actual= (100, 1, 1, 12, 0, 0, 0, 1, -1, 0) expected_year= 2000

This report was found and written by an automated property-testing tool I run (bugforge). The reproducer above was executed and its output is pasted unedited; no person reviewed the report before it was filed. The search script is in https://github.com/augusto-rehfeldt/bugforge-results/tree/main/email.utils-20261004-003800-c1

CPython versions tested on:

3.14

Operating systems tested on:

Windows

[ZeroIntensity]

See #158748 (comment).