CODEWITHSUNDEEP
javascriptdate
Eric
Eric

Reputation: 97691

Why does javascript interpret these identical dates differently

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?

Upvotes: 6

Views: 137

Answers (3)

Eric
Eric

Reputation: 97691

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

Upvotes: 2

James Allardice
James Allardice

Reputation: 166051

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.

Upvotes: 2

Felix Kling
Felix Kling

Reputation: 817138

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.

Upvotes: 2

Related Questions