The Short Answer
In addition to this, there is a second standard set forward by the IETF that browsers tend to follow as well, which is the definition for timestamps made in the RFC 2822. Actual documentation can be found in the references list at the bottom.
From this you can expect basic functionality, but what “ought” to be is not inherently what “is”. I’m going to go a little in depth with this procedurally though, as it appears only three people actually answered the question (Scott, goofballLogic, and peller namely) which, to me, suggests most people are unaware of what actually happens when you create a Date object.
The Long Answer
Where is the documentation which lists the format specifiers supported by the Date() object?
When a single argument is passed to new Date(), it casts this function prototype:
When two or more arguments are passed to new Date(), it casts this function prototype:
new Date (year, month [, date [, hours [, minutes [, seconds [, ms ] ] ] ] ] )
Both of those functions should look familiar, but this does not immediately answer your question and what quantifies as an acceptable “date format” requires further explanation. When you pass a string to new Date(), it will call the prototype (note that I'm using the word prototype loosely; the versions may be individual functions, or it may be part of a conditional statement in a single function) for new Date(value) with your string as the argument for the “value” parameter. This function will first check whether it is a number or a string. The documentation for this function can be found here:
From this, we can deduce that to get the string formatting allowed for new Date(value), we have to look at the method Date.parse(string). The documentation for this method can be found here:
And we can further infer that dates are expected to be in a modified ISO 8601 Extended Format, as specified here:
Google’s V8, date.js, DateConstructor
Looking at the DateConstructor function, we can deduce we need to find the DateParse function; however, note that “year” is not the actual year and is only a reference to the “year” parameter.
Google’s V8, date.js, DateParse
This calls %DateParseString, which is actually a run-time function reference for a C++ function. It refers to the following code:
Google’s V8, runtime.cc, %DateParseString
The function call we’re concerned with in this function is for DateParser::Parse(); ignore the logic surrounding those function calls, these are just checks to conform to the encoding type (ASCII and UC16). DateParser::Parse is defined here:
Google's V8, dateparser-inl.h, DateParser::Parse
This is the function that actually defines what formats it accepts. Essentially, it checks for the EMCAScript 5.0 ISO 8601 standard and if it is not standards compliant, then it will attempt to build the date based on legacy formats. A few key points based on the comments:
- Words before the first number that are unknown to the parser are ignored.
- Parenthesized text are ignored.
- Unsigned numbers followed by “:” are interpreted as a “time component”.
- Unsigned numbers followed by “.” are interpreted as a “time component”, and must be followed by milliseconds.
- Signed numbers followed by the hour or hour minute (e.g. +5:15 or +0515) are interpreted as the timezone.
- When declaring the hour and minute, you can use either “hh:mm” or “hhmm”.
- Words that indicate a time zone are interpreted as a time zone.
- All other numbers are interpreted as “date components”.
- All words that start with the first three digits of a month are interpreted as the month.
- You can define minutes and hours together in either of the two formats: “hh:mm” or “hhmm”.
- Symbols like “+”, “-“ and unmatched “)” are not allowed after a number has been processed.
- Items that match multiple formats (e.g. 1970-01-01) are processed as a standard compliant EMCAScript 5.0 ISO 8601 string.
So this should be enough to give you a basic idea of what to expect when it comes to passing a string into a Date object. You can further expand upon this by looking at the following specification that Mozilla points to on the Mozilla Developer Network (compliant to the IETF RFC 2822 timestamps):
The Microsoft Developer Network additionally mentions an additional standard for the Date object: ECMA-402, the ECMAScript Internationalization API Specification, which is complementary to the ECMAScript 5.1 standard (and future ones). That can be found here: