Closed Bug 1023155 Opened 10 years ago Closed 10 years ago

Data.parse behaviour does not match description in referenced RFC 2822

Categories

(Developer Documentation Graveyard :: JavaScript, defect)

All
Other
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: silas.orting, Assigned: fs)

Details

(Whiteboard: [specification][type:bug])

What did you do?
================
1. new Date('10 06 2014').toString()

What happened?
==============
"Mon Oct 06 2014 00:00:00 GMT+0200 (CEST)"

What should have happened?
==========================
"Tue Jun 10 2014 00:00:00 GMT+0200 (CEST)"

Is there anything else we should know?
======================================
According to the description
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse
Date.parse "accepts the RFC2822 / IETF date syntax (RFC2822 Section 3.3)" http://tools.ietf.org/html/rfc2822#page-14.
The RFC has 
date            =       day month year
which should give Jun 10 2014 from 10 06 2014.

According to
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.4.2 
behaviour is implementation defined if the format string does not conform to 
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15
which gives the format as YYYY-MM-DDTHH:mm:ss.sssZ
Assignee: nobody → fscholz
Component: General → JavaScript
Product: Mozilla Developer Network → Developer Documentation
Thanks for the bug Silas. MDN is a wiki, so you can edit the https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse page yourself if you like.
(In reply to Luke Crouch [:groovecoder] from comment #1)
> Thanks for the bug Silas. MDN is a wiki, so you can edit the
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/
> Global_Objects/Date/parse page yourself if you like.

I can do that, but I would like to find out what the actual behaviour is first and if the implementation defined behaviour is stable.
I assume there is some specification that is followed, so I just have to find it. Any ideas for how I can find it?
The spec is available via this table: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#Specifications

Click on EcmaScript 6 and it will send you right at the right position in the latest spec.
(In reply to Jean-Yves Perrier [:teoli] from comment #3)
> The spec is available via this table:
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/
> Global_Objects/Date/parse#Specifications
> 
> Click on EcmaScript 6 and it will send you right at the right position in
> the latest spec.

The format defined in the standard is YYYY-MM-DDTHH:mm:ss.sssZ
And 
"If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats."

So what I am looking for is a specification of the "implementation-specific heuristics or implementation-specific date formats" that is actually used.

I am looking for the implementation-defined
Till, can you give us information about a SpiderMonkey specific implementation of the date format?
(Or CC someone who might know)
Flags: needinfo?(till)
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.
Flags: needinfo?(till)
Thanks, Till.

I left a note here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#Fall-back_to_implementation-specific_date_formats
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.