Skip to content

gh-126845: Some edge cases in email.utils.parsedate_to_datetime seem to differ from RFC2822 spec #134438

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
gostak-dd wants to merge 16 commits into from
+31 −1
Closed

gh-126845: Some edge cases in email.utils.parsedate_to_datetime seem to differ from RFC2822 spec #134438

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
a84d66c
added digit check to prevent forced 4-digit year evaluation
gostak-dd May 21, 2025
df899ea
added tests for obscure year inputs to parsedate_to_datetime
gostak-dd May 21, 2025
6112424
updated test_email to correctly assert 1 digit year
gostak-dd May 21, 2025
639514f
📜🤖 Added by blurb_it.
blurb-it[bot] May 21, 2025
5dccaeb
Added newline at end of test_parsedate_to_datetime.py
gostak-dd May 21, 2025
83bdc71
removed trailing whitespace in parsedate_to_datetime
gostak-dd May 21, 2025
1575dc3
Merge branch 'main' into bugfix/parsedate_to_datetime
gostak-dd May 30, 2025
3cba685
fixed 3-digit year edge case
gostak-dd Jul 17, 2025
da6ff70
reset year check to previous value
gostak-dd Jul 17, 2025
693bce3
moved ParsedateToDatetimeTest
gostak-dd Jul 17, 2025
87fef0c
change yy to < 1000
gostak-dd Jun 2, 2026
9a40eed
updated test edge cases
gostak-dd Jun 2, 2026
5f589ba
Update 2025-05-21-15-32-04.gh-issue-126845.QhEGg6.rst
bitdancer Jun 2, 2026
19ed6c3
Merge branch 'main' into bugfix/parsedate_to_datetime
bitdancer Jun 2, 2026
526cafd
Update 2025-05-21-15-32-04.gh-issue-126845.QhEGg6.rst
bitdancer Jun 2, 2026
67ded8f
Update 2025-05-21-15-32-04.gh-issue-126845.QhEGg6.rst
bitdancer Jun 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion Lib/email/_parseaddr.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,6 @@ def _parsedate_tz(data):
# The year is between 1969 and 1999 (inclusive).
if yy > 68:
yy += 1900
# The year is between 2000 and 2068 (inclusive).
Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why removed this comment? It was accurate.

else:
yy += 2000
tzoffset = None
Expand Down
24 changes: 24 additions & 0 deletions Lib/test/test_email/test_utils.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,30 @@ def test_parsedate_to_datetime_with_invalid_raises_valueerror(self):
with self.subTest(dtstr=dtstr):
self.assertRaises(ValueError, utils.parsedate_to_datetime, dtstr)

def test_parsedate_to_datetime_year_edge_cases(self):
expectations = {
# Various short-year formats that get expanded
"Sat, 15 Aug 0001 23:12:09 +0500": "2001",
"Thu, 1 Sep 1 23:12:09 +0800": "2001",
"Thu, 7 Oct 123 23:12:09 +0500": "2023",
"Tue, 17 Nov 2026 12:12:09 +0500": "2026",
# RFC 5322 section 4.3 boundaries for 2-digit years
"Mon, 1 Jan 0 00:00:00 +0000": "2000",
"Mon, 1 Jan 68 00:00:00 +0000": "2068",
"Mon, 1 Jan 69 00:00:00 +0000": "1969",
"Mon, 1 Jan 99 00:00:00 +0000": "1999",
# 3-digit year boundary
"Mon, 1 Jan 999 00:00:00 +0000": "2899",
Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the result is not 999?

Copy link
Copy Markdown
Member

@bitdancer bitdancer Jun 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the RFC says it should be interpreted by adding 1900, which is what the PR is going to fix.

# Pre-1900 four-digit year: illegal per RFC but we accept it
"Mon, 1 Jan 1000 00:00:00 +0000": "1000",
}
for input_string, expected_year in expectations.items():
with self.subTest(input_string=input_string):
self.assertEqual(
str(utils.parsedate_to_datetime(input_string))[:4],
expected_year,
)

class LocaltimeTests(unittest.TestCase):

def test_localtime_is_tz_aware_daylight_true(self):
Expand Down
7 changes: 7 additions & 0 deletions Misc/NEWS.d/next/Library/2025-05-21-15-32-04.gh-issue-126845.QhEGg6.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
Fixed the :mod:`email` module parsing of three digit dates to
Copy link
Copy Markdown
Member

@serhiy-storchaka serhiy-storchaka Jun 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only change is removing a comment and adding a test. I do not think this NEWS entry is still relevant.

Copy link
Copy Markdown
Member

@bitdancer bitdancer Jun 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, the PR got messed up by my using the web to try to resolve the merge conflict, It's current state does not represent its intent, and all should be clear once it gets straightened out.

conform to :rfc:`5322`: three digit dates were previously
turned in to non-conformant four digit dates with a
leading ``0``. Now, per the RFC section 4.3, ``1990`` is added
to such dates to form compliant four digit years.

Contributed by Gustaf Gyllensporre.
Loading