TB 126.96.36.199, Win2K I've got several feeds set up on Craig's List. When the items come down, they have the post date listed twice in the XML: <dc:date>2007-08-27T22:48:42-0700</dc:date> <dcterms:issued>2007-08-27T22:48:42-0700</dcterms:issued> But the item in my RSS folder has these two headers: From - Mon, 27 Aug 2007 22:48:42 GMT Date: Mon, 27 Aug 2007 22:48:42 GMT The date & time values have been parsed OK, but the -0700 TZ indicator has been dropped. As a result, the timestamp of the item in the thread pane and envelope panel appears as: 27-Aug-2007 3:48PM instead of 10:48PM, which would be correct (as I'm in the same -0700 TZ). I'd really like to not have to remember to add seven hours every time I look at one of these.
my memory is pretty faulty these days but I seem to remember Phil working on some RSS date/time formatting...
Mike, could you please attach an example feed? Every time I try to look at RSS bugs, there seems to be nothing but links to feeds that no longer bear any resemblance to what the bug describes them as having shown.
(In reply to comment #0) > <dc:date>2007-08-27T22:48:42-0700</dc:date> Hmm, -hh:mm without a colon, I wouldn't be surprised if we interpret that as saying 22:48:42 minus 700 hours, and decide that we're not going to subtract 700.
Timezone specs don't normally have colons, tho. Try this link: http://sfbay.craigslist.org/search/fur?addTwo=by-owner &maxAsk=500&minAsk=300&query=sofa&srchType=T&format=rss (All one line of course.)
RFC (2)822 date-times don't have colons in the timezone, but W3C date-times, the subset of ISO 8601 that's (generally) used in dc:date, do - http://www.w3.org/TR/NOTE-datetime And as usual, my first guess was wrong - (Z|([+-])(\d\d):(\d\d))? doesn't think it's 700, it thinks that it's something, anything, which is not a timezone indicator. Given several hundred testcases and a harness to run them, I'd be willing to try making that colon optional (so, it may well happen first in the copy of the function that toolkit's parser uses). (Coincidentally, the opposite of this, no colon in RFC (2)822 timezones, was one of the primary reasons that feedvalidator.org exists.)
Created attachment 278724 [details] Craigslist feed And I wasn't kidding about "attach" - there's at least a half-dozen Tb feed bugs that I'd work on, but all the linked feeds don't currently exhibit the described problem, and I've got no way of telling whether the description of how they used to be is inaccurate, or what.
D'oh! I didn't try to validate, my bad. Changing this to an RFE to handle the bogus format. And sorry about misunderstanding the 'attach' part -- I did in fact have a wget'd copy of the feed on my disk. I'll also send a nag off to Craig's List and see if, maybe someday, they can fix their feed.
Severity: minor → enhancement
Summary: RSS item's date failing to abide by timezone (-0700) indicator in feed → Smart handling of incorrectly-formatted date fields (timezone of "-0700" instead of "-07:00")
fwiw, Craig's List has fixed their feeds' dates.
Component: RSS → Feed Reader
Product: Thunderbird → MailNews Core
Version: 2.0 → 1.8 Branch
I have been bitten by this as well, more recently. Wikispot.org uses RSS timestamps of the form <dc:date>2010-09-30 18:40:46</dc:date>. FF 3.6.10 and TB 3.1.4 interpret this date/time to be the same as 2010-09-30Z00:00+00:00, when in fact it is meant to be 18:40:46 local time (-07:00, in this case (PDT)). IE8 interprets the above RSS timestamp to be 2010-09-30Z18:40:46+00:00, which is also not what was intended, but somewhat more useful. Opera, however, merely interprets it as the desired local time. The fact that Opera does the "right thing" despite the fact that the timestamp does not conform to the standard (where I use the term "right thing" loosely), indicates to me that this is a common timestamp error, and therefore might be worth an enhancement to handle it.
I probably should have included a url. You can see this behavior at http://wikispot.org/recent_changes , and look at the rss link.
The wikispot thing is not this bug, and as you and others correctly filed it against wikispot, is multiple bugs in their date formatting. What this bug was about, is fixed by bug 682754.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.