333547 - Accept (invalid) UTC as a synonym for UT/GMT in RSS <pubDate>s

Status: RESOLVED WONTFIX

(MailNews Core :: Feed Reader, defect)

Description

[Ulrich Windl]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921

Thunderbird 1.5 seems to use the time when it retrieved an RSS (v2.0) item as date of the message, but not the (optional) <pubDate> of the <item>

Reproducible: Always

Steps to Reproduce:
1. Retrieve messages from some RSS v2.0 feed that defines <pubDate>

Actual Results:  
Date and time being displayed for the item is the retrioeval time, not the item's <pubDate> nor the <channel's <lastBuildDate>

Expected Results:  
If present, the item's <pubDate> should be used as time of the item in the summary display

Comment 1

[Ulrich Windl]

Attachment: Sample RSS v2.0 file

Note: This is taken from Intranet, so the URIs won't work.

Comment 2

[zug_treno]

Maybe related to bug 320677?

Comment 3

[Mike Cowperthwaite]

Maybe.  The <pubdate> in the sample data isn't RFC3339, but there still might 
be a problem with parsing the date.  I tried using the URL to the attachment as a feed URL in TB 3a1-0329 (I'm not sure if that's a valid test) and the item was shown dated today rather than last Friday.

So, I'll confirm; Robert can correct me if I'm wrong.

Comment 4

[Robert Sayre]

RSS 2.0 uses RFC822 dates. Feeds should use "UT" or "GMT", not "UTC". 

http://feedvalidator.org/check.cgi?url=https://bugzilla.mozilla.org/attachment.cgi?id=217999

If the /mail date parser can deal with "UTC", I'll change the code to allow this. 

Comment 5

[troy]

If possible, please allow for a missing timezone as well.
I'm reading a feed that does that :(

Comment 6

[Dave Miller [:justdave]]

Yeah, this is pretty annoying trying to monitor an SMF forum with RSS... if more than one person posts between two feed downloads, the posts show up out of order and it's impossible to follow the thread.

Comment 7

[alta88]

(In reply to comment #6)
> Yeah, this is pretty annoying trying to monitor an SMF forum with RSS... if
> more than one person posts between two feed downloads, the posts show up out of
> order and it's impossible to follow the thread.
> 

yeah, that sure is annoying.  perhaps contacting the forum and introducing them to feedvalidator.org is the better course of action here.

here's a good one from Yahoo: http://feedvalidator.org/check.cgi?url=http%3A%2F%2Ffinance.yahoo.com%2Frss%2Fheadline%3Fs%3Dibm

i propose this is a wontfix, with the addition of a console message stating something like "Feed <feed url> pubDate (publication date/time) follows incorrect RFC822 format, using current date/time".  in fact, the only way to fix these format issues is to log 'em and tell the user.  lack of a message here is a big strategic error.

Comment 8

[Phil Ringnalda (:philor)]

I'm all about beating up publishers with the Stupid Stick, but I don't think Thunderbird's error console is a very effective place to do it, or that this is a battle worth fighting (see also bug 369672, which will make it moot once someone finds the time to switch us to the toolkit parser).

Comment 9

[Phil Ringnalda (:philor)]

Attachment: Fix v.1

Sure, God will kill a kitten every time this code runs, but there are lots of kittens, aren't there?

Comment 10

[alta88]

well, now you have a dead kitten (probly an Amur tiger cub too).  what about that Yahoo format??  just a half 'a line of code to fix that..  if you don't then i completely fail to see your logic here and you shouldn't quote RFCs anymore.

the console is *totally* underused.  it's incorrect to have next to no error or message logging.  but this is the moz mindset, less worth battling.

Comment 11

[Phil Ringnalda (:philor)]

If you really can't see the difference between UTC->UT and Etc/GMT->UT, then I guess it's no wonder the world so rarely pleases you.

Comment 12

[alta88]

you've misunderstood (on many levels), but the relevant one is:

Etc/GMT -> GMT

Comment 13

[Phil Ringnalda (:philor)]

You're right, I haven't a clue whether by that you mean "only Etc/GMT -> GMT, and still fail with Etc/GMT-0, Etc/GMT+0, Etc/GMT0, Etc/Greenwich, Etc/UTC, Etc/UCT, Etc/Universal, and all the Etc/GMT+/-somethings" or "support all Etc/ timezones." Nor am I able to see any direct slippery slope which leads from "for the one instance in RFC822 dates where the correct abbreviation is something that nobody uses, accept the abbreviation that everyone knows instead" to "support (all or part of) the world's second most confusing timezone specification."

Comment 14

[Robert Sayre]

The tone here is not good. The patch is in the bug. No more noise please.

Comment 15

[Phil Ringnalda (:philor)]

Comment on attachment 326235 [details] [diff] [review]
Fix v.1

Actually, I think this is the wrong thing in the wrong place: for some reason, every time we call PR_ParseTimeString we pass false for default_to_gmt, despite the oddly-placed bit in 2822's obsolete date-time formats section saying that (at least) unrecognized [A-Za-z]{3,5} should be treated as -0000. With that fixed, we could just pass through UTC unchanged, let it be unrecognized and thus default to just what it should be.