Closed Bug 1023155 Opened 10 years ago Closed 10 years ago

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


(Developer Documentation Graveyard :: JavaScript, defect)

Not set


(Not tracked)



(Reporter: silas.orting, Assigned: fs)


(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
Date.parse "accepts the RFC2822 / IETF date syntax (RFC2822 Section 3.3)"
The RFC has 
date            =       day month year
which should give Jun 10 2014 from 10 06 2014.

According to 
behaviour is implementation defined if the format string does not conform to
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 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
> 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:

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:
> 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
"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:

If that fails, another parsing algorithm takes over, which starts here:

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:
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.