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

NEW
Unassigned

Status

()

Core
JavaScript: Standard Library
--
enhancement
7 years ago
a year ago

People

(Reporter: philor, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: js-triage-needed)

(Reporter)

Description

7 years ago
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.
Whiteboard: js-triage-needed
(Reporter)

Comment 1

7 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

4 years ago
Assignee: general → nobody
Blocks: 1274354
Component: JavaScript Engine → JavaScript: Standard Library
You need to log in before you can comment on or make changes to this bug.