difference between new Date("2017-01-01") and new Date("2017-1-1")
new Date("2017-01-01")
is in-spec (more below). new Date("2017-1-1")
is not, and so falls back on any "...implementation-specific heuristics or implementation-specific date formats" the JavaScript engine wants to apply. E.g., you have no guarantee how (or whether) it will successfully parse and if so, whether it will be parsed as UTC or local time.
Although new Date("2017-01-01")
is in-spec, sadly what browsers are supposed to do with it has been a moving target, because it doesn't have a timezone indicator on it:
- In ES5 (December 2009), strings without a timezone indicator were supposed to be parsed as UTC. But that's at variance with the ISO-8601 standard the date/time format is based on, which says strings without a timezone indicator are meant to be local time, not UTC. So in ES5,
new Date("2017-01-01")
is parsed in UTC.
- In ES2015 (aka ES6, June 2015), strings without a timezone indicator were supposed to be local time, not UTC, like ISO-8601. So in ES2015,
new Date("2017-01-01")
is parsed as local time.
- But, that was changed again in ES2016 (June 2016) because browsers had been parsing date-only forms with
-
in them as UTC for years. So as of ES2016, date-only forms (like "2017-01-01"
) are parsed in UTC, but date/time forms (like "2017-01-01T00:00:00"
) are parsed in local time.
Sadly, not all JavaScript engines currently implement the spec. Chrome (as of this writing, v56) parses date/time forms in UTC even though they should be local time (so does IE9). But Chrome, Firefox, and IE11 (I don't have IE10 or Edge handy) all handle date-only forms correctly (as UTC). IE8 doesn't implement the ISO-8601 form at all (having been released before the ES5 spec was released).