682781 - date_parseString should understand the single-letter RFC 822 military timezone abbreviations

Status: RESOLVED DUPLICATE of bug 1852422

(Core :: JavaScript: Standard Library, enhancement)

Description

[Phil Ringnalda (:philor)]

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.

Comment 1

[Phil Ringnalda (:philor)]

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.

Comment 2

[Vinny Diehl]

This was added in bug 1852422.