Pourquoi "2016-02-16" n'est-il pas égal à "2016-02-16 00:00"?

J'essaye de passer les deux chaînes de date à new Date(t).

Je m'attends à ce que les deux chaînes représentent la même heure, après tout, si j'omets l'heure, ne devrait-il pas être minuit ce jour-là?

Mais en même temps,

new Date("2016-02-16 00:00")

renvoie 16/02/2016, minuit, heure locale comme prévu,

new Date("2016-02-16")

renvoie 16/02/2016, minuit UTC, ce qui est faux, ou du moins pas ce à quoi je m'attendais étant donné ce que l'autre chaîne analyse.

Je comprendrais qu'ils aient tous les deux le même comportement, que ce soit pour renvoyer l'heure comme heure locale ou comme UTC, mais il semble très incohérent pourquoi ils renvoient des choses différentes comme celle-ci.

Comme solution de contournement, chaque fois que je rencontre une date qui n'a pas d'horodatage correspondant, je peux ajouter "00:00" pour obtenir un comportement cohérent, mais il semble que cela soit plutôt fragile.

J'obtiens cette valeur d'un élément INPUT, de type 'datetime-local', il semble donc particulièrement incohérent que je doive contourner une valeur retournée par un élément de page.

Est-ce que je fais quelque chose de mal ou devrais-je faire quelque chose différemment?

C'est ce que dit la spécification ES5.1 :

La valeur d'un décalage de fuseau horaire absent est «Z».

Il dit aussi:

La fonction tente d'abord d'analyser le format de la chaîne selon les règles appelées dans le format de chaîne de date et d'heure (15.9.1.15). Si la chaîne n'est pas conforme à ce format, la fonction peut revenir à n'importe quelle heuristique spécifique à l'implémentation ou aux formats de date spécifiques à l'implémentation.

Étant donné que le format nécessite un Tséparateur entre la date et l'heure, les heures valides vont à 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)

... tandis que dans node.js, une heure invalide (sans le séparateur T) semble aller à l'heure locale spécifique à l'implémentation:

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

Notez que ES6 a changé cela, dans la même partie de la documentation qu'il change:

Si le décalage de fuseau horaire est absent, la date-heure est interprétée comme une heure locale.

La joie de rompre les changements .

Éditer

Selon TC39 , la spécification est censée être interprétée comme des chaînes de date et d'heure sans fuseau horaire (par exemple, "2016-02-16T00: 00: 00") sont traitées comme locales (selon ISO 8601), mais uniquement les chaînes de date (par exemple "2016-02-16") comme UTC (ce qui est incompatible avec l'ISO 8601).

Selon les spécifications :

La fonction tente d'abord d'analyser le format de la chaîne selon les règles appelées dans le format de chaîne de date et d'heure (15.9.1.15). Si la chaîne n'est pas conforme à ce format, la fonction peut revenir à n'importe quelle heuristique spécifique à l'implémentation ou aux formats de date spécifiques à l'implémentation.

Et les formats de chaîne de date et d' heure acceptent 2016-02-16comme date valide

Ce format inclut les formulaires à date uniquement:

AAAA
AAAA-MM
AAAA-MM-JJ

[...] Si les champs HH, mm ou ss sont absents, «00» est utilisé comme valeur et la valeur d'un champ sss absent est «000». La valeur d'un décalage de fuseau horaire absent est «Z».

Ainsi se 2016-02-16traduit par 2016-02-16T00:00:00.000Z.

L'autre date 2016-02-16 00:00n'est pas conforme au format et son analyse est donc spécifique à l'implémentation. Apparemment, ces dates sont traitées comme ayant un fuseau horaire local et votre exemple de date renverra des valeurs différentes selon le fuseau horaire:

/* 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

Résumé:

• Pour les formats de date et d'heure conformes, le comportement est bien défini - en l'absence de décalage de fuseau horaire, la chaîne de date est traitée comme UTC (ES5) ou locale (ES6).
• Pour les formats de date et d'heure non conformes, le comportement est spécifique à l'implémentation - en l'absence de décalage de fuseau horaire, le comportement habituel est de traiter la date comme locale.
• En fait, l'implémentation pourrait choisir de revenir NaNau lieu d' essayer d'analyser les dates non conformes. Testez simplement votre code dans Internet Explorer 11;)

Vous rencontrez peut-être des différences entre les implémentations ES5, ES6 et le résultat attendu. Par date.parse chez MDN, "en particulier dans les différentes implémentations ECMAScript où des chaînes telles que" 2015-10-12 12:00:00 "peuvent être analysées en tant que NaN, UTC ou fuseau horaire local" est significative.

Des tests supplémentaires dans Firefox 44 et IE 11 ont révélé qu'ils renvoyaient tous deux un objet de date pour new Date("2016-02-16 00:00") , lequel objet renvoie NaN lors de la tentative d'obtention d'une valeur de composant de date, et dont la valeur toString est "Date invalide" (et non "NaN"). Par conséquent, l'ajout de "00:00 pour obtenir un comportement cohérent" peut facilement se briser dans différents navigateurs.

Comme indiqué dans d'autres réponses, new Date("2016-02-16")utilise un décalage de fuseau horaire de zéro par défaut, produisant minuit UTC au lieu de local.

Par DateParser::Parse()code source V8 pour Chrome.

Dates ES5 ISO 8601:

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

Un nombre non signé suivi de «:» est une valeur de temps et est ajouté à TimeComposer.

le fuseau horaire est par défaut Z s'il est absent

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

Une chaîne qui correspond à deux formats (par exemple 1970-01-01) sera analysé comme une chaîne date-heure ES5 - ce qui signifie qu'il sera par défaut UTC time-zone. C'est inévitable si vous suivez la spécification ES5.

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

renvoie 16/02/2016, minuit UTC, ce qui est faux, ou du moins pas ce à quoi je m'attendais étant donné ce que l'autre chaîne analyse.

Il ajoute le décalage du fuseau horaire au 00:00

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

Mon fuseau horaire étant IST avec une valeur de décalage (en minutes) +330, il a donc ajouté 330 minutes à 00:00.

Selon ecma-262, section 20.3.3.2 Date.parse (chaîne)

Si ToString entraîne un achèvement brutal, l'enregistrement d'achèvement est immédiatement renvoyé. Sinon, parse interprète la chaîne résultante comme une date et une heure; il renvoie un nombre, la valeur de l'heure UTC correspondant à la date et à l'heure. La chaîne peut être interprétée comme une heure locale, une heure UTC ou une heure dans un autre fuseau horaire, selon le contenu de la chaîne.

Lorsque vous définissez explicitement les unités de temps, new Date("2016-02-16 00:00")il utilisera défini comme hourset minutes,

Sinon, comme indiqué ici en 2 0.3.1.16

Si le décalage de fuseau horaire est absent, la date-heure est interprétée comme une heure locale.