Why isn't “2016-02-16” equal to “2016-02-16 00:00”?

Question

I\'m trying to pass both date strings to new Date(t).

I expect both strings represent the same time, after all, if I omit the time, shouldn\'t it be mid

Answer 1

You are perhaps running into a differences between ES5, ES6 implementations and your expected result. Per Date.parse at MDN, "especially across different ECMAScript implementations where strings like "2015-10-12 12:00:00" may be parsed to as NaN, UTC or local timezone" is significant.

Additional testing in Firefox 44 and IE 11 revealed they both return a date object for new Date("2016-02-16 00:00"), which object returns NaN when atttempting to get a date component value, and whose toString value is "Invalid Date" (not "NaN"). Hence appending " 00:00 to get consistent behavior" can easily break in different browsers.

As noted in other answers new Date("2016-02-16") uses a timezone offset of zero by default, producing midnight UTC instead of local.

Answer 2

returns 2016-02-16, midnight UTC, which is wrong, or at least not what I expected given what the other string parses as.

It adds the timezone offset to the 00:00

new Date("2016-02-16") outputs Tue Feb 16 2016 05:30:00 GMT+0530 (India Standard Time)

My timezone being IST with an offset value (in minutes) +330, so it added 330 minutes to 00:00.

As per ecma-262, section 20.3.3.2 Date.parse ( string )

If ToString results in an abrupt completion the Completion Record is immediately returned. Otherwise, parse interprets the resulting String as a date and time; it returns a Number, the UTC time value corresponding to the date and time. 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.

When you explicitly set the time-units new Date("2016-02-16 00:00") it wll use set that as hours and minutes,

Otherwise as stated here in 20.3.1.16

If the time zone offset is absent, the date-time is interpreted as a local time.

Answer 3

Per DateParser::Parse() of V8 source codes for Chrome.

ES5 ISO 8601 dates:

[('-'|'+')yy]yyyy[-MM[-DD]][THH:mm[:ss[.sss]][Z|(+|-)hh:mm]]

An unsigned number followed by ':' is a time value, and is added to the TimeComposer.

timezone defaults to Z if missing

> new Date("2016-02-16 00:00")
  Tue Feb 16 2016 00:00:00 GMT+0800 (China Standard Time)

A string that matches both formats (e.g. 1970-01-01) will be parsed as an ES5 date-time string - which means it will default to UTC time-zone. That's unavoidable if following the ES5 specification.

> new Date("2016-02-16")
Tue Feb 16 2016 08:00:00 GMT+0800 (China Standard Time)

Answer 4

According to the specifications:

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 Date Time String Formats accept 2016-02-16 as a valid date

This format includes date-only forms:

YYYY
YYYY-MM
YYYY-MM-DD

[...] If the HH, mm, or ss fields are absent “00” is used as the value and the value of an absent sss field is “000”. The value of an absent time zone offset is “Z”.

Thus 2016-02-16 translates to 2016-02-16T00:00:00.000Z.

The other date 2016-02-16 00:00 does not conform to the format and therefore its parsing is implementation specific. Apparently, such dates are treated as having local time zone and your example date will return different values depending on time zone:

/* tz = +05:00 */ new Date("2016-02-16 00:00").toISOString() // 2016-02-15T19:00:00.000Z
/* tz = -08:00 */ new Date("2016-02-16 00:00").toISOString() // 2016-02-16T08:00:00.000Z

Summary:

• For conforming date time formats the behavior is well defined — in the absence of time zone offset the date string is treated as UTC (ES5) or local (ES6).
• For non-conforming date time formats the behavior is implementation specific — in the absence of time zone offset the usual behavior is to treat the date as local.
• As a matter of fact, the implementation could choose to return NaN instead of trying to parse non-conforming dates. Just test your code in Internet Explorer 11 ;)

Answer 5

It's what the ES5.1 specification says to do:

The value of an absent time zone offset is “Z”.

It also says:

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.

Since the format requires a T separator between date and time, the valid times go to UTC:

> new Date("2016-02-16T00:00:00")
Tue Feb 16 2016 01:00:00 GMT+0100 (CET)
> new Date("2016-02-16")
Tue Feb 16 2016 01:00:00 GMT+0100 (CET)

...while in node.js, an invalid time (without the T separator) seems to go to the implementation specific localtime:

> new Date("2016-02-16 00:00:00")
Tue Feb 16 2016 00:00:00 GMT+0100 (CET)

Note that ES6 changed this, in the same part of the documentation it changes to:

If the time zone offset is absent, the date-time is interpreted as a local time.

The joy of breaking changes.

Edit

According to TC39, the specification is meant to be interpreted as date and time strings without a time zone (e.g. "2016-02-16T00:00:00") are treated as local (per ISO 8601), but date only strings (e.g. "2016-02-16") as UTC (which is inconsistent with ISO 8601).