"2017-01-01" follows the ISO standard ES5 Date Time String format (simplification of ISO 8601 Extended Format), and therefore it is in UTC time, which is 8am in China. All other strings are parsed as local time in Chrome1.
1 Relevant source code in Chromium: https://cs.chromium.org/chromium/src/v8/src/dateparser-inl.h?type=cs&l=16
Date parsing in Chromium follows the standard ES5 rules as well as these extra rules:
- Any unrecognized word before the first number is ignored.
- Parenthesized text is ignored.
- An unsigned number followed by
: is a time value, and is added to the TimeComposer. A number followed by :: adds a second zero as well. A number followed by . is also a time and must be followed by milliseconds. Any other number is a date component and is added to DayComposer.
- A month name (or really: any word having the same first three letters as a month name) is recorded as a named month in the
Day composer.
- A word recognizable as a time-zone is recorded as such, as is
(+|-)(hhmm|hh:).
- Legacy dates don't allow extra signs (
+ or -) or unmatched ) after a number has been read (before the first number, any garbage is allowed).
- Any strings that satisfy the ES5 rules and the rules above will be parsed using ES5 rules. This means
"1970-01-01" will be in UTC time-zone not in local time-zone.
What does that mean?
First note that "2017-01-01" is parsed in UTC time because it is a "date" string instead of a "date-time" string, and it matches the ES5 definition of a "date" string. If time is attached, then it will follow the ISO standard and parse it in local time.
Examples:
2017-01-01 - Jan 1, 2017 in UTC time2017-01-01T00:00 - Jan 1, 2017 in local time2017-1-1 - Jan 1, 2017 in local time2017-(hello)01-01 - Jan 1, 2017 in local timemay 2017-01-01 - May 1, 2017 in local timemayoooo 2017-01-01 - May 1, 2017 in local time"jan2017feb-mar01apr-may01jun" - Jun 1, 2017 in local time
