Thanks to visit codestin.com
Credit goes to github.com

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

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

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
7 commits
Select commit Hold shift + click to select a range
a84d66c
added digit check to prevent forced 4-digit year evaluation
GGyll May 21, 2025
df899ea
added tests for obscure year inputs to parsedate_to_datetime
GGyll May 21, 2025
6112424
updated test_email to correctly assert 1 digit year
GGyll 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
GGyll May 21, 2025
83bdc71
removed trailing whitespace in parsedate_to_datetime
GGyll May 21, 2025
1575dc3
Merge branch 'main' into bugfix/parsedate_to_datetime
GGyll May 30, 2025
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
2 changes: 1 addition & 1 deletion Lib/email/_parseaddr.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -149,7 +149,7 @@ def _parsedate_tz(data):
# calls for a two-digit yy, but RFC 2822 (which obsoletes RFC 822)
# mandates a 4-digit yy. For more information, see the documentation for
# the time module.
if yy < 100:
if len(str(yy)) >= 2 and yy < 100:
Copy link
Member

Choose a reason for hiding this comment

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

yy is now a number, so if yy < 100 (and it's positive), len(str(yy)) >= 2 is never true.
You need to keep the original year string for this check.

# The year is between 1969 and 1999 (inclusive).
if yy > 68:
yy += 1900
Expand Down
2 changes: 1 addition & 1 deletion Lib/test/test_email/test_email.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3227,7 +3227,7 @@ def test_parsedate_y2k(self):

"""
self.assertEqual(utils.parsedate_tz('25 Feb 03 13:47:26 -0800'),
utils.parsedate_tz('25 Feb 2003 13:47:26 -0800'))
utils.parsedate_tz('25 Feb 3 13:47:26 -0800'))
Copy link
Member

Choose a reason for hiding this comment

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

This makes the test ineffective.

self.assertEqual(utils.parsedate_tz('25 Feb 71 13:47:26 -0800'),
utils.parsedate_tz('25 Feb 1971 13:47:26 -0800'))

Expand Down
17 changes: 17 additions & 0 deletions Lib/test/test_email/test_parsedate_to_datetime.py
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Test to see if parsedate_to_datetime returns the correct year for different digit numbers, adhering to the RFC2822 spec

import unittest
from email.utils import parsedate_to_datetime

class ParsedateToDatetimeTest(unittest.TestCase):
Copy link
Member

Choose a reason for hiding this comment

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

parsedate_to_datetime tests belong in test_utils in DateTimeTests. (Those tests could maybe use some refactoring, but let's ignore that ;)

def test(self):
expectations = {
"Sat, 15 Aug 0001 23:12:09 +0500": "0001",
"Thu, 1 Sep 1 23:12:09 +0800": "0001",
Copy link
Member

Choose a reason for hiding this comment

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

Logically when doing a Postel "be generous in what you accept" recovery here, a single digit year should be treated as if it were a two digit year, which means the result here should 2001, which is what the current code produces.

"Thu, 7 Oct 123 23:12:09 +0500": "0123",
Copy link
Member

Choose a reason for hiding this comment

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

And this result should be 2023, per the rfc text you quoted (three digit years get 1900 added). I have no idea why that settled on that logic, it makes no sense to me, but that's what the RFC says.

}
for input_string, output_string in expectations.items():
Copy link
Member

Choose a reason for hiding this comment

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

subTest would be good here.

self.assertEqual(str(parsedate_to_datetime(input_string))[:4], output_string)

if __name__ == '__main__':
unittest.main()
2 changes: 2 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,2 @@
Fixed _parsedate_tz to not evaluate 1 digit years as as 4-digit years, adhering to RFC 2855 4.3
Contributed by Gustaf Gyllensporre.
Loading