Why javascript interprets 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, each is interpreted as UTC, while the other two are interpreted as local time. What makes the difference in the analysis?

+6
source share
3 answers

From specification :

A string can be interpreted as local time, UTC, or time in some other time zone, depending on the contents of the string . First, the function tries to analyze the format of the string in accordance with the rules written in the format of the date-time string format ( 15.9.1.15 ). If String does not conform to this format, the function can return to any implementation-specific heuristic, or to implementation date formats.

Of all the formats that you have provided, only '2013-04-15' officially supported, so the rest seems to be returning to implementation-dependent dependencies.

+2
source

The Date constructor delegates Date.parse , and it seems that Date.parse has two options:

For a string representing time, parse returns the time value. This takes the syntax of RFC2822 / IETF (RFC2822, section 3.3) , for example. "Mon, December 25, 1995 13:30:00 GMT." He understands the continental US abbreviations in the time zone, but for general use, use the time zone offset, for example, "Mon, December 25, 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 considered . GMT and UTC are considered equivalent.

Alternatively, the date / time string may be in ISO 8601 . Starting with JavaScript 1.8.5 (Firefox 4), a subset of ISO 8601. For example, “2011-10-10” (date only) or “2011-10-10T14: 48: 00 (date and time) can be transmitted and analyzed.

Clearly, they behave differently with respect to local time zones.


Edit: It looks like this implementation is defined

+2
source

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

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

The parse method will try to parse string (highlighted by me):

A string can be interpreted as local time, UTC, or time in some other time zone, depending on the contents of the string . First, the function tries to analyze the format of the string in accordance with the rules written in the format of the time string in time (15.9.1.15).

If the string does not match this format, the function can return to any heuristic specific to a particular implementation, or to date formats of a specific version .

And the format of the date string in time 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.

In other examples, parsing is not performed, and the behavior is determined by the implementation.

+2
source

All Articles