"2017-01-01" sigue el formato de cadena de fecha y hora ES5 del estándar ISO (simplificación del formato extendido ISO 8601) y, por lo tanto, está en hora UTC, que son las 8 a. m. en China. Todas las demás cadenas se analizan como hora local en Chrome ¹ .

¹ Código fuente relevante en Chromium: https://cs.chromium.org/chromium/src/v8/src/dateparser-inl.h?type=cs&l=16

El análisis de fechas en Chromium sigue las reglas estándar de ES5, así como estas reglas adicionales:

• Cualquier palabra no reconocida antes del primer número se ignora.
• El texto entre paréntesis se ignora.
• Un número sin signo seguido de : es un valor de tiempo y se agrega a TimeComposer . Un número seguido de :: agrega un segundo cero también. Un número seguido de . es también un tiempo y debe ir seguido de milisegundos. Cualquier otro número es un componente de fecha y se agrega a DayComposer .
• El nombre de un mes (o realmente: cualquier palabra que tenga las mismas tres primeras letras que el nombre de un mes) se registra como un mes con nombre en el compositor de Day .
• Una palabra reconocible como zona horaria se registra como tal, como (+|-)(hhmm|hh:) .
• Las fechas heredadas no permiten signos adicionales ( + o - ) o no coincidentes ) después de que se haya leído un número (antes del primer número, se permite cualquier basura).
• Cualquier cadena que cumpla con las reglas de ES5 y las reglas anteriores se analizará utilizando las reglas de ES5. Esto significa que "1970-01-01" estará en la zona horaria UTC, no en la zona horaria local.

¿Qué significa eso?

Primero tenga en cuenta que "2017-01-01" se analiza en hora UTC porque es una cadena de "fecha" en lugar de una cadena de "fecha-hora", y coincide con la definición de ES5 de una cadena de "fecha". Si se adjunta la hora, seguirá el estándar ISO y la analizará en la hora local.

Ejemplos:

• 2017-01-01 - 1 de enero de 2017 en hora UTC
• 2017-01-01T00:00 - 1 de enero de 2017 en hora local
• 2017-1-1 - 1 de enero de 2017 en hora local
• 2017-(hello)01-01 - 1 de enero de 2017 en hora local
• may 2017-01-01 - 1 de mayo de 2017 en hora local
• mayoooo 2017-01-01 - 1 de mayo de 2017 en hora local
• "jan2017feb-mar01apr-may01jun" - 1 de junio de 2017 en hora local

diferencia entre nueva fecha ("2017-01-01") y nueva fecha ("2017-1-1")

La new Date("2017-01-01") está dentro de las especificaciones (más información a continuación). new Date("2017-1-1") no lo es, por lo que recurre a cualquier "... heurística específica de implementación o formatos de fecha específicos de implementación" que el motor de JavaScript quiera aplicar. Por ejemplo, no tiene garantía de cómo (o si) se analizará con éxito y, de ser así, si se analizará como UTC o como hora local.

Aunque la new Date("2017-01-01") está dentro de las especificaciones, lamentablemente lo que se supone que deben hacer los navegadores ha sido un objetivo móvil, porque no tiene un indicador de zona horaria:

• En ES5 (diciembre de 2009), se suponía que las cadenas sin un indicador de zona horaria se analizarían como UTC. Pero eso está en desacuerdo con el estándar ISO-8601 en el que se basa el formato de fecha/hora, que dice que las cadenas sin un indicador de zona horaria deben ser hora local, no UTC. Entonces, en ES5, la new Date("2017-01-01") se analiza en UTC.
• En ES2015 (también conocido como ES6, junio de 2015), se suponía que las cadenas sin indicador de zona horaria eran hora local, no UTC, como ISO-8601. Entonces, en ES2015, la new Date("2017-01-01") se analiza como la hora local.
• Pero eso se cambió nuevamente en ES2016 (junio de 2016) porque los navegadores habían estado analizando formularios de solo fecha con - en ellos como UTC durante años. Entonces, a partir de ES2016, los formularios de solo fecha (como "2017-01-01" ) se analizan en UTC, pero los formularios de fecha/hora (como "2017-01-01T00:00:00" ) se analizan en hora local.

Lamentablemente, no todos los motores de JavaScript implementan actualmente la especificación. Chrome (a partir de este escrito, v56) analiza los formularios de fecha/hora en UTC aunque deberían ser la hora local (también lo hace IE9). Pero Chrome, Firefox e IE11 (no tengo IE10 o Edge a mano) manejan formularios de solo fecha correctamente (como UTC). IE8 no implementa el formulario ISO-8601 en absoluto (ya que se lanzó antes de que se lanzara la especificación ES5).

Al analizar las fechas, JavaScript interpreta las fechas ISO como la hora UTC y otros formatos como la hora local.

Como sugiere el artículo de MDN ,

Cuando la cadena es solo la fecha ISO 8601, se utiliza la zona horaria UTC para interpretar los argumentos.

Dada una cadena de fecha de "7 de marzo de 2014", parse() asume una zona horaria local, pero dado un formato ISO como "2014-03-07", asumirá una zona horaria de UTC (ES5 y ECMAScript 2015) . Por lo tanto, los objetos de fecha producidos con esas cadenas pueden representar diferentes momentos en el tiempo según la versión de ECMAScript admitida, a menos que el sistema esté configurado con una zona horaria local de UTC. Esto significa que dos cadenas de fecha que parecen equivalentes pueden dar como resultado dos valores diferentes según el formato de la cadena que se está convirtiendo.

 // 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()); }