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

Question

J'essaie 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-on pas dire minuit ce jour-là ?

Mais pendant ce temps,

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

rendements 2016-02-16, minuit, heure locale comme prévu,

new Date("2016-02-16")

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

Je comprendrais qu'ils aient tous deux le même comportement, qu'il s'agisse de renvoyer l'heure en tant qu'heure locale ou en tant qu'heure UTC, mais il semble très incohérent qu'ils renvoient des choses différentes comme cela.

Comme solution de rechange, 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 à partir d'un élément INPUT, de type "datetime-local". Il me semble donc particulièrement incohérent de devoir travailler avec une valeur renvoyée par un élément de page.

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

Answer 1

C'est ce que le Spécification ES5.1 dit de faire :

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

Il est également dit :

La fonction tente d'abord d'analyser le format de la chaîne conformément aux règles énoncées dans la section Format de la chaîne date-heure (15.9.1.15). Si la chaîne n'est pas conforme à ce format, la fonction peut se rabattre sur toute heuristique ou format de date spécifique à l'implémentation.

Puisque le format exige un T séparateur entre la date et l'heure, les heures valides passent en 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)

...alors que dans node.js, une heure non valide (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 l'ES6 modifié ceci, dans le même partie de la documentation il se transforme en :

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

La joie de les modifications de rupture .

Editar

Según TC39 Si l'on considère que la spécification doit être interprétée de la manière suivante : les chaînes de date et d'heure sans fuseau horaire (par exemple, "2016-02-16T00:00:00") sont traitées comme des chaînes locales (conformément à la norme ISO 8601), mais les chaînes de date uniquement (par exemple, "2016-02-16") sont traitées comme des chaînes UTC (ce qui est incompatible avec la norme ISO 8601).

Answer 2

Según la spécifications :

La fonction tente d'abord d'analyser le format de la chaîne de caractères (String) selon les règles énoncées dans Date Time String Format (15.9.1.15). Si la chaîne n'est pas conforme à ce format, la fonction format, la fonction peut se rabattre sur des heuristiques ou des formats de date formats de date spécifiques à l'implémentation.

Et Formats des chaînes de date et d'heure accepter 2016-02-16 comme une date valable

Ce format inclut les formulaires à date unique :

YYYY
YYYY-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 champ sss absent absent est "Z".

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

L'autre date 2016-02-16 00:00 ne se conforme pas 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

Resumen:

• 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, la fonction habituel est de traiter la date comme locale.
• En fait, l'implémentation pourrait choisir de retourner NaN au lieu de en essayant pour analyser les dates non conformes. Testez votre code dans Internet Explorer.

Answer 3

Vous vous heurtez peut-être à une différence entre les implémentations ES5, ES6 et votre résultat attendu. Par Date.parse sur MDN, "en particulier à travers différentes implémentations ECMAScript où des chaînes comme "2015-10-12 12:00:00" peuvent être interprétées comme NaN, UTC ou fuseau horaire local" est significatif.

Des tests supplémentaires dans Firefox 44 et IE 11 ont révélé qu'ils renvoient tous les deux un objet date pour new Date("2016-02-16 00:00") Cet objet renvoie NaN lorsqu'il tente d'obtenir une valeur de composant de date, et sa valeur toString est la suivante "Invalid Date" (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 ainsi le minuit UTC au lieu du local.

Answer 4

Par DateParser::Parse() des codes sources de 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 temporelle, et est ajouté au TimeComposer.

le fuseau horaire prend la valeur Z par défaut 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 aux deux formats (par ex. 1970-01-01 ) sera analysé comme une chaîne de date et d'heure ES5 - ce qui signifie qu'il aura la valeur par défaut suivante UTC time-zon e. C'est inévitable si l'on suit la spécification ES5.

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

Answer 5

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

Il ajoute le décalage du fuseau horaire à la 00:00

new Date("2016-02-16") 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 donc il a ajouté 330 minutes à 00:00.

Conformément à ecma-262, section 20.3.3.2 Date.parse ( string )

Si ToString aboutit à une fin abrupte, l'enregistrement de fin est immédiatement retourné. Sinon, parse interprète la chaîne résultante comme une date et une heure ; il retourne un nombre, la valeur de l'heure UTC correspondant à la date et à l'heure. La chaîne peut être interprétée comme une l'heure locale, l'heure UTC ou l'heure d'un autre fuseau horaire, en fonction de l'heure locale. du contenu de la chaîne.

Quand vous explicitement définir les unités de temps new Date("2016-02-16 00:00") il utilisera cet ensemble comme hours y 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 un heure locale.