Closed
Bug 682781
Opened 13 years ago
Closed 6 months ago
date_parseString should understand the single-letter RFC 822 military timezone abbreviations
Categories
(Core :: JavaScript: Standard Library, enhancement)
Core
JavaScript: Standard Library
Tracking
()
RESOLVED
DUPLICATE
of bug 1852422
People
(Reporter: philor, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: js-triage-needed)
new Date("Mon, 24 Aug 2009 19:15:00 +0000") (an RFC822 datetime) is a valid date; new Date("Mon, 24 Aug 2009 19:15:00 Z") (an equivalent RFC822 datetime) is an Invalid Date, but the toolkit feed parser would like it to be a valid date for bug 512307. Because RFC822 messed up the sign on the non-0000 ones, RFC2822 says in http://tools.ietf.org/html/rfc2822#page-31 that every one of them, A-I and K-Z, are equal, all meaning -0000. Silly me, I thought that ought to be easy to implement, just stick all the letters in wtb[] and 25 "10000 + 0,"s in ttb[], but apparently something in the uncommented and obscured mass of date_parseString causes it to need something more than just that.
Updated•13 years ago
|
Whiteboard: js-triage-needed
Reporter | ||
Comment 1•13 years ago
|
||
Okay, here's your js-triage: There's no ECMAScript spec issue here: Z is recognized in strings matching ES5's profile of ISO 8601; ES3 only requires that you parse what you emit, and we never emit Z so we don't have to parse it. There's no Java spec issue here: horribly, our date parsing is based on the long-deprecated http://download.oracle.com/javase/1.4.2/docs/api/java/util/Date.html#parse%28java.lang.String%29 which does not support Z or any other single-letter timezone. The first two characters of almost everything in wtb[] in http://mxr.mozilla.org/mozilla-central/source/js/src/jsdate.cpp#527 are unique while the first characters are not, so http://mxr.mozilla.org/mozilla-central/source/js/src/jsdate.cpp#1043 treats finding a one character word as a syntax error, and matches two character or more words to the start of the strings in wtb[] in reverse order. There is in fact a Java spec error in there, because there's two pairs that aren't two character unique, Ma(rch) and Ma(y) and Ju(ne) and Ju(ly), and we get it backward: by going through wtb[] in reverse, we call 1 Ma 2011 May when it should be March, which is easily fixed but uninteresting to me and probably a bad idea to fix given how long its been that way and how uninteresting compatibility with a deprecated Java method is. Possibly it's also a Java spec error to not treat the one character weekday prefixes that cannot be month names, T and W, as valid weekday names to be ignored, but again, don'tcare. The fix for this bug would be to replace that "if (i <= st + 1) goto syntax" with... probably if it's z it's +0000, else goto syntax. Even slightly encouraging people to use A-I and K-Y really isn't a very good idea.
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•2 years ago
|
Severity: normal → S3
Comment 2•6 months ago
|
||
This was added in bug 1852422.
You need to log in
before you can comment on or make changes to this bug.
Description
•