1

MDN's documentation for Date.parse says:

Parameters

dateString A string representing an RFC822 or ISO 8601 date.

Description

The parse method takes a date string (such as "Dec 25, 1995") and returns the number of milliseconds since January 1, 1970, 00:00:00 UTC. The local time zone is used to interpret arguments that do not contain time zone information. This function is useful for setting date values based on string values, for example in conjunction with the setTime method and the Date object.

Given a string representing a time, parse returns the time value. It accepts the RFC822 / IETF date syntax (RFC 1123 Section 5.2.14 and elsewhere), e.g. "Mon, 25 Dec 1995 13:30:00 GMT". It understands the continental US time-zone abbreviations, but for general use, use a time-zone offset, for example, "Mon, 25 Dec 1995 13:30:00 GMT+0430" (4 hours, 30 minutes east of the Greenwich meridian). If you do not specify a time zone, the local time zone is assumed. GMT and UTC are considered equivalent.

Alternatively, the date/time string may be in ISO 8601 format. Starting with JavaScript 1.8.5 / Firefox 4, a subset of ISO 8601 is supported. For example, "2011-10-10" (just date) or "2011-10-10T14:48:00 (date and time) can be passed and parsed. Timezones in ISO dates are not yet supported, so e.g. "2011-10-10T14:48:00+0200" (with timezone) does not give the intended result yet.

However:

var t = new Date("4/25/2010");
console.log(t);

// Output: Sun Apr 25 2010 00:00:00 GMT+0100 (GMT Daylight Time)

Where is it written that it should support the MM/dd/yyyy format?

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
Royi Namir
  • 144,742
  • 138
  • 468
  • 792

1 Answers1

2

It isn't. The baseline requirements are outlined in the spec but implementations are allowed to support additional formats of their choosing.

The String may be interpreted as a local time, a UTC time, or a time in some other time zone, depending on the contents of the String. The function first attempts to parse the format of the String according to the rules called out in Date Time String Format (15.9.1.15). If the String does not conform to that format the function may fall back to any implementation-specific heuristics or implementation-specific date formats.

Obviously, these can vary widely, and some commonly used formats are ambiguous such as "1/2/1970" which might be the first of February or the second of January. If you want to write cross-platform code, only rely on the baseline formats in 15.9.1.15.

EDIT:

Re the difference between YYYY-MM-DD and YYYY/MM/DD, the first is speced as returning that date with a zero time, whereas the second is not specified so an implementation is allowed to produce any date it likes. The relevant portion of the sepc is

This format includes date-only forms:

  • YYYY
  • YYYY-MM
  • YYYY-MM-DD

...

All numbers must be base 10. If the MM or DD fields are absent “01” is used as the value. If the mm or ss fields are absent “00” is used as the value and the value of an absent sss file is “000”. The value of an absent time zone offset is “Z”.

Community
  • 1
  • 1
Mike Samuel
  • 118,113
  • 30
  • 216
  • 245
  • please run http://jsbin.com/atupok/5/edit#javascript,html in ie and chrome. different results......... – Royi Namir Jan 28 '12 at 15:36
  • @RoyiNamir And? Is there another question? – Dave Newton Jan 28 '12 at 15:39
  • @dave 1) why on http://jsbin.com/atupok/5/edit#javascript,html in Ie i get NAN ....2)why there are different results in http://jsbin.com/atupok/6/edit ? – Royi Namir Jan 28 '12 at 15:41
  • @RoyiNamir: You're trying to reason about what, as you yourself pointed out, is undocumented (and implementation-defined) _additional_ behaviour. Just don't do that. – Lightness Races in Orbit Jan 28 '12 at 15:44
  • @RoyiNamir, NaN is the result of a failure to parse. http://es5.github.com/#x15.9.4.2 says "Unrecognizable Strings or dates containing illegal element values in the format String shall cause `Date.parse` to return NaN." – Mike Samuel Jan 28 '12 at 15:45
  • 1
    @mike **Is it possible that http://jsbin.com/atupok/7/edit will fail in ie althought its a baseline** format ? – Royi Namir Jan 28 '12 at 15:47
  • @RoyiNamir Of course it's *possible*. I'm pleasantly surprised when *anything* works in IE. – Dave Newton Jan 28 '12 at 15:49
  • @RoyiNamir, if it does then it's a bug in IE. `Date.parse('2011-11-23')` should be the same as `Date.parse('2011-11-23T00:00:00')` on any conforming implementation. – Mike Samuel Jan 28 '12 at 15:51