Closed Bug 1023155 Opened 8 years ago Closed 7 years ago
.parse behaviour does not match description in referenced RFC 2822
Assignee: nobody → fscholz
Product: Mozilla Developer Network → Developer Documentation
Till, can you give us information about a SpiderMonkey specific implementation of the date format? (Or CC someone who might know)
The standardized ISO format is parsed in ParseISODate: http://mxr.mozilla.org/mozilla-central/source/js/src/jsdate.cpp?rev=64553c483cd1#763 If that fails, another parsing algorithm takes over, which starts here: http://mxr.mozilla.org/mozilla-central/source/js/src/jsdate.cpp?rev=64553c483cd1#889 As a very rough outline, the way this works is: 1. year, month, and day are initialized to -1 2. the input is iterated over starting in line 903 3. the if condition in line 925 is matched for each iteration of the loop 4. the while loop in lines 927-930 parses each full number literal, so the first iteration results in `10`, the second in `6` and the third in `2014` 5. since no other conditions are met, the first iteration assigns to the `mon` variable in line 992, the second to `mday` in line 994, and the third to `year` in line 996 I guess it's somewhat obvious how the rest plays out. Note that this behavior is matched by Chrome, whereas Safari creates an invalid date for this constructor argument. I don't know what IE does, but my guess would be that they match Firefox and Chrome.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.