Last Comment Bug 394119 - "Wrong" time from dc:date without a colon in timezone offset
: "Wrong" time from dc:date without a colon in timezone offset
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: RSS Discovery and Preview (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://bugzilla.mozilla.org/attachme...
Depends on: 682754
Blocks: 394113
  Show dependency treegraph
 
Reported: 2007-08-28 22:36 PDT by Phil Ringnalda (:philor, back in August)
Modified: 2011-10-13 23:05 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Phil Ringnalda (:philor, back in August) 2007-08-28 22:36:19 PDT
Craigslist RSS feeds use invalid dc:date values, along the lines of <dc:date>2007-08-28T21:38:22-0700</dc:date> when the timezone offset should instead be -07:00 with a colon. Since the regex in W3CToIETFDate() is already ensuring that there's [+-] in front of four digits coming after everything else we want, it ought to be safe to make the colon optional.

STR:
1. Load attachment 278724 [details], a Craigslist search feed as of 2007-08-27.
2. Note that the preview lists the first item with a date of "Tue, Aug 28, 2007 2:38 PM" (if you're in PDT, as I am now), the result of treating 21:38:22 as a UTC time, rather than showing it as "9:38 PM", the intended time.
Comment 1 Robert Sayre 2007-08-28 23:08:30 PDT
I think it's ok to fish for invalid field values as long as we don't break any valid dates.
Comment 2 Phil Ringnalda (:philor, back in August) 2007-08-28 23:47:06 PDT
Which makes step 1 "verify that we have test coverage for every possible form of W3CDTF." (And step 2 "worry about ISO 8601 forms which are not W3CDTF" but I'm not spending CHF 126.00 for a copy of the spec.)
Comment 3 Robert Sayre 2007-08-28 23:55:23 PDT
(In reply to comment #2)
> Which makes step 1 "verify that we have test coverage for every possible form
> of W3CDTF." 

mmm, ok, I can buy that. maybe lose the melodrama and say "lots of w3cdtf tests". ;)

> (And step 2 "worry about ISO 8601 forms which are not W3CDTF" but
> I'm not spending CHF 126.00 for a copy of the spec.)

Nope, ISO8601 does much more than timestamps, but no feed date element allows anything but timestamps. The unpleasant interaction of RFC 3339 with xsdDateTame is probably the nastiest case we have to deal with:

http://www.imc.org/atom-syntax/mail-archive/msg13103.html
Comment 4 Phil Ringnalda (:philor, back in August) 2007-08-29 22:00:49 PDT
(In reply to comment #3)
> no feed date element allows anything but timestamps.

Sadly, that's not the case. Either the RSS 1.0 authors didn't read the part of http://www.w3.org/TR/NOTE-datetime which says "An adopting standard must specify which of these options it permits" or they meant to allow all six granularities, but didn't read the part that says "If a given standard allows more than one granularity, it should specify the meaning of the dates and times with reduced precision" so for dc:date in RSS 1.0, <dc:date>2007-08-29</dc:date> is an absolutely valid value, with an undefined relationship to values like <dc:date>2007-08-29 00:00:00</dc:date>.

Since ISO 8601 is well-designed, I don't see any way that allowing no-colon timezones will get anything wrong, as long as it's after [+-], but we still should be testing that we're getting our best-guess at what RSS 1.0 would have specified if they did their job, 2007 == 2007-01-01T00:00:00.0-00:00.
Comment 5 Robert Sayre 2007-08-29 22:11:45 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > no feed date element allows anything but timestamps.
> 
> Sadly, that's not the case.

Yes, sad. We'll do the best we can with non-timestamp values, but we'll probably be buggy there until we can incorporate a real ISO8601 parser, hopefully in a library that we can share across the product.
Comment 6 Phil Ringnalda (:philor, back in August) 2011-10-13 23:05:07 PDT
Fixed by bug 682754.

Note You need to log in before you can comment on or make changes to this bug.