[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Serhiy Storchaka added the comment: >>> email.utils.parsedate_to_datetime(None) Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/email/utils.py", line 200, in parsedate_to_datetime raise ValueError('Invalid date value or format "%s"' %

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Change by Barry A. Warsaw : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.8, Python 3.9 ___ Python tracker ___

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

miss-islington added the comment: New changeset 303aac8c56609290e122eecc14c038e9b1e4174a by Georges Toth in branch 'master': bpo-30681: Support invalid date format or value in email Date header (GH-22090) https://github.com/python/cpython/commit/303aac8c56609290e122eecc14c038e9b1e4174a

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Change by Ned Deily : -- nosy: -ned.deily versions: -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Barry A. Warsaw added the comment: Aside: I noticed that on _parseaddr.py:68, there's a bare `return`. That should really be `return None` (EIBTI). Can you fix that in your PR? I think it's confusing to raise both TypeError and ValueError. I suggest we check the `None` return from

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Georges added the comment: @barry Thank you for your input on the PR. >From what I understood this PR was nearly ready and only missing a small >addition to the documentation which I added. So it took me a bit to go through >it all :-). I actually don't see how *parsedate_to_datetime*

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Barry A. Warsaw added the comment: @sim0n - I added a comment to your open PR. My main question for the rest of the group is whether we can and should backport this. Given the new defect class being introduced, it seems like this should only land in 3.10. Thoughts? --

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Georges added the comment: As I think it is still important to have this fixed and considering the original PR was closed, I have created a new PR based on the original one while implementing the requested changes. https://github.com/python/cpython/pull/22090 -- versions: +Python

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Change by Georges : -- nosy: +sim0n nosy_count: 4.0 -> 5.0 pull_requests: +21176 pull_request: https://github.com/python/cpython/pull/22090 ___ Python tracker ___

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Tim Bell added the comment: I've addressed the points in the last few comments and created a new PR (10783). -- ___ Python tracker ___

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Change by Tim Bell : -- keywords: +patch pull_requests: +10025 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

R. David Murray added the comment: Reported again in issue #35342. The existing PR is close to complete, but needs adjusted for the fact that we want (and want to document) that the utility raises errors (ie: catch the error in the header parser rather than having the utility return None).

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Barry A. Warsaw added the comment: So, while we do have a conflict between consistency and utility, I think @r.david.murry 's last comment has convinced me that raising the exception is more helpful. I think we should do that, fixing the documentation and giving up on the consistency issue.

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Changes by Nick Coghlan : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

R. David Murray added the comment: I'll make one argument in favor of retaining the exception, and if that doesn't fly then I agree to the solution and will try to review the PR soon. The argument is this: if parsedate_to_datetime raises an error, you get information about *why* the date was

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Tim Bell added the comment: I've updated the pull request to incorporate Barry's suggestion of a new defect for this situation, InvalidDateDefect. -- ___ Python tracker

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Barry A. Warsaw added the comment: Thanks for all the great detailed background, and the suggested approaches. I think there are a couple of constraints that would be good to resolve. * parsedate_to_datetime() is documented as "performing the same function as parsedate()" with an explicit

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Tim Bell added the comment: Thanks for the feedback. I've made a new pull request which addresses the points raised. -- ___ Python tracker ___

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Changes by Tim Bell : -- pull_requests: +2304 ___ Python tracker ___ ___

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

R. David Murray added the comment: OK, I think I've reloaded my brain at least partially on this topic. I think my original reason for having prasedate_to_datetime raise errors is that it was my opinion that that is the way it should work, and that parsedate should work the same way (raise

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Tim Bell added the comment: My proposed solution (in https://github.com/python/cpython/pull/2229) is two-part: 1. change parsedate_to_datetime() to return None rather than raising an exception; and 2. change headerregistry.DateHeader.parse() to check for None being returned from

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Barry A. Warsaw added the comment: I'm not sure it would be any better, but what about defining something like a DateFormatDefect and returning that? -- ___ Python tracker

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

R. David Murray added the comment: The problem is that if it returns None on parse failure, then you can't tell the difference between the header not existing and the date not being parseable. I don't have a solution for this problem. Suggestions welcome. (Note that this is only a problem

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

Changes by Tim Bell : -- pull_requests: +2274 ___ Python tracker ___ ___

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

New submission from Tim Bell: Python 3.6 documentation for email.utils.parsedate_to_datetime() says "Performs the same function as parsedate(), but on success returns a datetime." The docs for parsedate() say "If it succeeds in parsing the date...; otherwise None will be returned." By