6

What's going on here:

> new Date('Apr 15 2013');
Mon Apr 15 2013 00:00:00 GMT+0100 (GMT Daylight Time)
> new Date('04/15/2013');
Mon Apr 15 2013 00:00:00 GMT+0100 (GMT Daylight Time)
> new Date('2013-04-15');
Mon Apr 15 2013 01:00:00 GMT+0100 (GMT Daylight Time)

Obviously, one is being interpreted as UTC time, while the other two are being interpreted as local time. What causes the difference in parsing?

Eric
  • 95,302
  • 53
  • 242
  • 374

3 Answers3

2

From the specification:

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.

Of all the formats you provided, only '2013-04-15' is officially supported, so the others seem to fall back to implementation-dependent behavior.

Felix Kling
  • 795,719
  • 175
  • 1,089
  • 1,143
  • 1
    The section you quoted from MDN is likely detailing the Gecko implementation behaviour (since as the spec shows, this situation is left up to the implementation). – James Allardice Feb 20 '13 at 10:00
  • 1
    @Eric: It could be either an implementation detail for Firefox or an unofficial, but widely supported feature. Chrome seems to behave the same way, so it might be the latter. – Felix Kling Feb 20 '13 at 10:01
  • +1. This graphically highlights the dangers of trying to parse arbitrary date strings. The same caveats apply in other languages too (the quirks in php's `strtotime()` have to be seen to be believed). The best advice is always to accept dates either in a fixed known format, preferably `yyyy-mm-dd`, or simply to always use an integer timestamp. Anything else is playing with fire. This applies even more so when sending data between systems. And user input on a form should be with a calendar control rather than free-type. – SDC Feb 20 '13 at 10:04
2

The Date constructor delegates to Date.parse, and it appears that Date.parse has two variants:

Given a string representing a time, parse returns the time value. It accepts the RFC2822 / IETF date syntax (RFC2822 Section 3.3), 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.

Clearly, these behave differently with respect to local timezones

Edit: Looks like this is implementation defined

Community
  • 1
  • 1
Eric
  • 95,302
  • 53
  • 242
  • 374
2

Your third example is the only one that is actually explained by the spec. When you call the Date constructor with a single argument, this is what happens (where v is the string passed to the constructor):

Parse v as a date, in exactly the same manner as for the parse method (15.9.4.2); let V be the time value for this date.

The parse method will attempt to parse the string (emphasis added):

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.

And the "Date Time String Format" is YYYY-MM-DDTHH:mm:ss.sssZ, and also defines a shorter version of the form YYYY-MM-DD, which is what you use in your third example.

For the other examples, the parse will fail and the behaviour is implementation-defined.

James Allardice
  • 164,175
  • 21
  • 332
  • 312