What is the difference between the new date ("2017-01-01") and the new date ("2017-1-1")?

Question

I enter new Date("2017-01-01") in the chrome console, the output shows that its hour is 8, but new Date("2017-01-1") and new Date("2017-1-01") shows that their hour is 0, so how to analyze new Date(dateString) ?

 new Date("2017-01-01") // Sun Jan 01 2017 08:00:00 GMT+0800 (中国标准时间)* new Date("2017-01-1") // Sun Jan 01 2017 00:00:00 GMT+0800 (中国标准时间)* new Date("2017-1-1") // Sun Jan 01 2017 00:00:00 GMT+0800 (中国标准时间)* new Date("2017-1-01") // Sun Jan 01 2017 00:00:00 GMT+0800 (中国标准时间)* 

Answer 1

"2017-01-01" follows the ISO standard. ES5 Date Time String format (simplification of the ISO 8601 Extended format) , and therefore this is UTC time, which is 8 hours in China. All other lines are parsed as local time in Chrome ¹ .

---

¹ Corresponding source code in Chromium: https://cs.chromium.org/chromium/src/v8/src/dateparser-inl.h?type=cs&l=16

Chromium's date analysis complies with ES5 standard rules as well as these additional rules:

• Any unrecognized word before the first number is ignored.
• Playback in parentheses is ignored.
• The unsigned number followed by : is the time value and is added to the TimeComposer . The number followed by :: adds a second zero. The number to follow . is also time and must be followed by milliseconds. Any other number is a component of the date and is added to DayComposer .
• The name of the month (or indeed: any word that has the same first three letters as the name of the month) is recorded as a named month in the composer Day .
• A word recognized as a time zone is written as such as (+|-)(hhmm|hh:) .
• Outdated dates do not allow additional characters ( + or - ) or disparate ) after the number has been read (any garbage is allowed before the first number).
• Any strings that satisfy the ES5 rules and the rules above will be analyzed using ES5 rules. This means that "1970-01-01" will not be in the local time zone in the UTC time zone.

---

What does it mean?

First, note that “2017-01-01” is parsed in UTC because it is the string “date” instead of the string “date-time” and matches the ES5 definition of the string “date”. If time is attached, it will follow the ISO standard and analyze it in local time.

Examples:

• 2017-01-01 - January 1, 2017 at UTC
• 2017-01-01T00:00 - January 1, 2017 local time
• 2017-1-1 - January 1, 2017 local time
• 2017-(hello)01-01 - 01 January 2017 local time
• may 2017-01-01 - May 1, 2017 local time
• mayoooo 2017-01-01 - May 1, 2017 local time
• "jan2017feb-mar01apr-may01jun" - June 1, 2017 local time

Answer 2

difference between the new date ("2017-01-01") and the new date ("2017-1-1")

new Date("2017-01-01") is in the specification (see below for more details). new Date("2017-1-1") not, and therefore returns to any "... implementation-specific heuristics or specific implementation date formats" that the JavaScript engine wants to apply. For example, you have no guarantee of how (or will) it will be successfully disassembled, and if so, whether it will be analyzed as UTC or local time.

Although the new Date("2017-01-01") is in the specification, unfortunately what browsers should do with it, it was a moving target because it does not have a time zone indicator:

• In ES5 (December 2009), strings without a time zone indicator should be parsed as UTC. But unlike the ISO-8601 standard, the date and time format is based, which says that strings without a time zone indicator are for local time, and not for UTC. Thus, in ES5, new Date("2017-01-01") parsed in UTC.
• In ES2015 (aka ES6, June 2015), strings without a time zone indicator should have been local time, not UTC, for example, ISO -8601. So, in ES2015, new Date("2017-01-01") parsed as local time.
• But , which was again changed in ES2016 (June 2016), because browsers only analyzed form dates with - in them like UTC for many years. So, as in ES2016, date-only formats (for example, "2017-01-01" ) are parsed in UTC, but date / time forms (for example, "2017-01-01T00:00:00" ) are parsed locally time.

Unfortunately, not all JavaScript engines currently implement the specification. Chrome (starting with this entry, v56) parses UTC date / time forms, although they should be local (just like IE9). But Chrome, Firefox and IE11 (I don't have IE10 or Edge), all date formats are processed only (in UTC format). IE8 does not implement the ISO-8601 form at all (was released before the release of the ES5 specification).

Answer 3

When parsing dates, JavaScript interprets ISO dates as UTC and other formats as local time.

As the MDN Article suggests

If the string only has an ISO 8601 date, the UTC time zone is used to interpret the arguments.

Given the date string “March 7, 2014”, parse () accepts the local time zone, but taking into account the ISO format such as “2014-03-07”, it will accept the UTC time zone (ES5 and ECMAScript 2015) . Therefore, Date objects created using these strings can represent different times depending on the version supported by ECMAScript if the system is not installed with a local UTC time zone. This means that two date strings that are equivalent can lead to two different values ​​depending on the format of the string to be converted.

 // 2017-03-28 is interpreted as UTC time, // shown as 2017-03-28 00:00:00 in UTC timezone, // shown as 2017-03-28 06:00:00 in my timezone: console.log("ISO dates:"); var isoDates = [new Date("2017-03-28")]; for (var dt of isoDates) { console.log(dt.toUTCString() + " / " + dt.toLocaleString()); } // Other formats are interpreted as local time, // shown as 2017-03-27 18:00:00 in my timezone, // shown 2017-03-28 00:00:00 in my timezone: console.log("Other formats:"); var otherDates = [new Date("2017-3-28"), new Date("March 28, 2017"), new Date("2017/03/28")]; for (var dt of otherDates) { console.log(dt.toUTCString() + " / " + dt.toLocaleString()); } 

Answer 4

This format is an international standard (ISO format)

 new Date("2017-01-01") 

This ensures the same output across all browsers.

However, other formats may vary depending on the browser, as they are not so clearly defined.

As you can see, this format

 new Date("2017-1-1") 

successfully understands chrome but gives an error in IE 11