Bug report

Bug description:

email.utils.parsedate_to_datetime() raises OverflowError instead of the documented ValueError when a Date header has a year (or timezone offset) that is out of range for datetime.

import email.utils
email.utils.parsedate_to_datetime('Mon, 20 Nov 9999999999 12:00:00 +0000')

Actual:

OverflowError: signed integer is greater than maximum

Expected: ValueError. The documentation states that a ValueError is raised if the input does not contain a valid date. OverflowError is not a subclass of ValueError, so a caller catching ValueError, as the docs invite, does not catch this.

It also escapes through the modern header API: email.message_from_string('Date: Mon, 20 Nov 9999999999 12:00:00 +0000\n\n', policy=email.policy.default)['Date'].datetime raises OverflowError, because email.headerregistry.DateHeader only catches ValueError (to record an InvalidDateDefect). Once parsedate_to_datetime raises ValueError, that path records the defect as intended, instead of raising.

Tested on 3.13, 3.14, and main.

CPython versions tested on:

3.13, 3.14, CPython main branch

Operating systems tested on:

macOS

Linked PRs

• gh-153406: Raise ValueError, not OverflowError, for out-of-range dates in email.utils.parsedate_to_datetime #153407
• [3.13] gh-153406: Raise ValueError, not OverflowError, for out-of-range dates in email.utils.parsedate_to_datetime (GH-153407) #153433
• [3.14] gh-153406: Raise ValueError, not OverflowError, for out-of-range dates in email.utils.parsedate_to_datetime (GH-153407) #153434
• [3.15] gh-153406: Raise ValueError, not OverflowError, for out-of-range dates in email.utils.parsedate_to_datetime (GH-153407) #153435