Je pense que c'est un bug.
Quel est le comportement actuel ?
Actuellement, j'ai un bel objet de date qui se déconnecte
Ven 29 Avr 2016 13:33:00 GMT+0100 (BST)
Lorsque cet objet est ensuite POSTÉ via $http, ce qui suit est observé dans les requêtes réseau.
2016-04-28T12:33:00.000Z
Ainsi, l'objet $http soustrait une heure et supprime effectivement l'heure d'été britannique BST de l'heure. Cela est donc stocké dans la base de données sans ce décalage. Lorsque nous lisons immédiatement cette date, elle revient mais comment le système peut-il savoir que nous devons rajouter l'heure ?
Alors imaginez aussi que l'utilisateur se trouve dans un autre fuseau horaire..disons 5 heures à l'avance, puis le système soustraira 5 heures...Le temps est sensible au contexte dans lequel il est créé. en d'autres termes, les informations de fuseau horaire ne doivent pas être supprimées.
Je vois cela dans Chrome. Angulaire 1.4.2
Ce n'est pas quelque chose de spécifique à Angular. C'est le comportement standard de JSON.stringify
.
Fondamentalement, lors de la publication de données, $http
convertit en JSON (via JSON.stringify()
). En JavaScript, la représentation JSON d'un objet Date est sa forme ISO-8601 (ce que vous voyez dans l'onglet réseau).
Un objet Date n'a de toute façon pas d'informations de fuseau horaire, donc aucune information n'est supprimée. La locale actuelle (qui est totalement indépendante de la date représentée par les objets Date) a un décalage de fuseau horaire et le navigateur formate la date en fonction de ce décalage lorsqu'il console.log
le trouve.
Fermeture car ce n'est pas un problème avec Angular.
@gkalpak Tout d'abord, je pense qu'il n'est pas correct de dire que l'objet Date n'a pas d'informations de fuseau horaire. Lorsque nous créons une date par new Date(), les informations de fuseau horaire sont le fuseau local par défaut. Un objet Date a les méthodes getTimezoneOffset
et toISOString
. Lorsqu'elles sont appelées, ces méthodes renvoient la valeur de la zone, ce n'est rien que le navigateur imprime bien pour nous, ce sont des valeurs réelles dans l'objet Date.
new Date().getTimezoneOffset()
-330
new Date().toISOString()
"2018-12-04T05:40:37.399Z"
Deuxièmement, JSON.stringify()
ne supprime pas non plus la valeur de la zone, voici ce que nous avons vu dans la console du navigateur et c'est la même chose, le navigateur n'imprime rien de bien pour nous.
JSON.stringify({d:new Date()})
"{"d":"2018-12-04T05:42:08.973Z"}"
Donc, je crois toujours que si l'API rend une date ISO qui n'a pas cette valeur en millisecondes et que l'interface utilisateur utilise un sélecteur de date qui ne sélectionne qu'une date et modifie la date, alors Angular lors du renvoi de la date en convertissant au format ISO, il n'aura pas de millisecondes valeur.
Tout d'abord, je pense qu'il n'est pas correct de dire que l'objet Date n'a pas d'informations de fuseau horaire.
Je pense toujours qu'il est correct de dire que :grin: Un objet Date
_"représente un seul moment dans le temps [...] basé sur une valeur temporelle qui est le nombre de millisecondes depuis le 1er janvier 1970 UTC" _ (source : MDN ). Donc, fondamentalement, chaque instance de Date
ne connaît que cette valeur et toutes les autres représentations de celle-ci sont induites en fonction de ces informations plus l'état du système/locale (comme le décalage horaire).
Un objet Date a les méthodes
getTimezoneOffset
ettoISOString
.
Ce sont des méthodes sur le prototype Date
(source: MDN ), pas sur les objets Date
(aka instances) eux-mêmes.
Plus précisément, la valeur de getTimezoneOffset() dépend de la locale actuelle (paramètres du système hôte). C'est la raison pour laquelle il n'y a pas setTimezoneOffset()
méthode Date
sur le même système renvoient la même valeur pour getTimezoneOffset()
, par exemple :
const d1 = new Date('December 15, 2018 12:34:56'); // No timezone; uses the current system locale.
const d2 = new Date('December 15, 2018 12:34:56 GMT+10'); // Uses GTM+10 as timezone.
d1.getTimezoneOffset() === d2.getTimezoneOffset(); // true
Ainsi, les informations de fuseau horaire spécifiées dans une représentation de chaîne de date passée à Date
ne sont utilisées que pour analyser cette chaîne et la mapper à un moment spécifique comme décrit ci-dessus. L'objet Date
résultant ne sait rien des fuseaux horaires :smiley:
La méthode toISOString() n'imprime pas les informations de fuseau horaire comme vous l'avez suggéré. Il ajoute juste Z
à la fin, ce qui dénote UTC
.
Deuxièmement,
JSON.stringify()
ne supprime pas non plus la valeur de la zone
Comme expliqué ci-dessus, il utilise toISOString()
, qui exprime la valeur de la date en UTC (en ajoutant donc Z
à la fin pour l'indiquer). Il n'y a aucune information de fuseau horaire dans la chaîne renvoyée.
Donc, je crois toujours que si l'API rend une date ISO qui n'a pas cette valeur en millisecondes et que l'interface utilisateur utilise un sélecteur de date qui ne sélectionne qu'une date et modifie la date, alors Angular lors du renvoi de la date en convertissant au format ISO, il n'aura pas de millisecondes valeur.
Je n'ai aucune idée de ce que les millisecondes ont à voir avec ça. Nous parlions d'informations sur le fuseau horaire.
Encore une fois, cela n'a rien à voir avec AngularJS. C'est ainsi que les objets intégrés (tels que Date
et JSON
) interagissent les uns avec les autres.
Commentaire le plus utile
Je pense toujours qu'il est correct de dire que :grin: Un objet
Date
_"représente un seul moment dans le temps [...] basé sur une valeur temporelle qui est le nombre de millisecondes depuis le 1er janvier 1970 UTC" _ (source : MDN ). Donc, fondamentalement, chaque instance deDate
ne connaît que cette valeur et toutes les autres représentations de celle-ci sont induites en fonction de ces informations plus l'état du système/locale (comme le décalage horaire).#
Ce sont des méthodes sur le prototype
Date
(source: MDN ), pas sur les objetsDate
(aka instances) eux-mêmes.Plus précisément, la valeur de getTimezoneOffset() dépend de la locale actuelle (paramètres du système hôte). C'est la raison pour laquelle il n'y a pas
setTimezoneOffset()
méthodeDate
sur le même système renvoient la même valeur pourgetTimezoneOffset()
, par exemple :Ainsi, les informations de fuseau horaire spécifiées dans une représentation de chaîne de date passée à
Date
ne sont utilisées que pour analyser cette chaîne et la mapper à un moment spécifique comme décrit ci-dessus. L'objetDate
résultant ne sait rien des fuseaux horaires :smiley:La méthode toISOString() n'imprime pas les informations de fuseau horaire comme vous l'avez suggéré. Il ajoute juste
Z
à la fin, ce qui dénoteUTC
.#
Comme expliqué ci-dessus, il utilise
toISOString()
, qui exprime la valeur de la date en UTC (en ajoutant doncZ
à la fin pour l'indiquer). Il n'y a aucune information de fuseau horaire dans la chaîne renvoyée.#
Je n'ai aucune idée de ce que les millisecondes ont à voir avec ça. Nous parlions d'informations sur le fuseau horaire.
Encore une fois, cela n'a rien à voir avec AngularJS. C'est ainsi que les objets intégrés (tels que
Date
etJSON
) interagissent les uns avec les autres.