rfc822 module bug?

[Nemesis]

Hi all,
I found that the function parsedate_tz of the rfc822 module has a bug
(or at least I think so).
I found a usenet article (message-id: <[email protected]>)
that has this Date field:

Date: Tue,26 Jul 2005 13:14:27 GMT +0200

It seems to be correct¹, but parsedate_tz is not able to decode it, it
is confused by the absence of a space after the ",".
I studied the parsedate_tz code and the problem is on its third line:
....
if not data:
return None
data = data.split()
....
After the split I have:

['Tue,26', 'Jul', '2005', '13:14:27', 'GMT', '+0200']

but "Tue," and "26" should be separated.

Of course parsedate_tz correctly decode the field if you add a space
after the ",".

Do you think that's a bug?
Which is the most correct place where to file this bug?


¹ and looking at rfc822 par3.3 it should be correct:

date-time = [ day-of-week "," ] date FWS time [CFWS]

day-of-week = ([FWS] day-name) / obs-day-of-week

day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"

date = day month year

 

[Dennis Lee Bieber]

Which is the most correct place where to file this bug?

Uh, with the software the created that DATE: header?

Does RFC822 (or modern replacement) permit the lack of a space
in that position? The spec is somewhat vague on spacing for dates, only
indicating that the text day is optional and, if present, has a comma
after it.

5.1. SYNTAX

date-time = [ day "," ] date time ; dd mm yy
; hh:mm:ss zzz

--

 

[Cliff Wells]

Hi all,
I found that the function parsedate_tz of the rfc822 module has a bug
(or at least I think so).
I found a usenet article (message-id: <[email protected]>)
that has this Date field:

Date: Tue,26 Jul 2005 13:14:27 GMT +0200

My preferred date/time module is Gustavo Niemeyer's DateUtil module:

https://moin.conectiva.com.br/DateUtil

It parses an astounding number of date formats (I used it to parse the
mess of dates and times provided by RSS feeds without a hitch).

Regards,
Cliff

 

[Tim Roberts]

Hi all,
I found that the function parsedate_tz of the rfc822 module has a bug
(or at least I think so).
I found a usenet article (message-id: <[email protected]>)
that has this Date field:

Date: Tue,26 Jul 2005 13:14:27 GMT +0200

It seems to be correct¹, but parsedate_tz is not able to decode it, it
is confused by the absence of a space after the ",".

Fascinating. I've written a lot of e-mail programs, and I would have bet
real money that this was not legal by either RFC822 or 2822, but the BNF
certainly supports your assertion that this is valid.

RFC1036, which gives the format for Usenet articles, includes the space in
its "suggested" date format.

¹ and looking at rfc822 par3.3 it should be correct:

date-time = [ day-of-week "," ] date FWS time [CFWS]

day-of-week = ([FWS] day-name) / obs-day-of-week

day-name = "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"

date = day month year

This is actually from RFC2822, but the point is the same.

 

[Nemesis]

Mentre io pensavo ad una intro simpatica "Tim Roberts" scriveva:

[rfc822 module bug]

Date: Tue,26 Jul 2005 13:14:27 GMT +0200

It seems to be correct¹, but parsedate_tz is not able to decode it, it
is confused by the absence of a space after the ",".

Fascinating. I've written a lot of e-mail programs, and I would have bet
real money that this was not legal by either RFC822 or 2822, but the BNF
certainly supports your assertion that this is valid. [...]
This is actually from RFC2822, but the point is the same.

Yes you are right of course.

I think I'll submit this bug on the Python web-site.