Angular.js: $http modifie la date dans l'objet POSTED JSON (supprime le fuseau horaire ou le décalage saisonnier)

Créé le 25 avr. 2016  ·  3Commentaires  ·  Source: angular/angular.js

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

Aussi http://stackoverflow.com/questions/24356475/angular-js-date-changes-when-submitting-to-http-timezone-issue

Commentaire le plus utile

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 et toISOString .

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.

Tous les 3 commentaires

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 et toISOString .

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.

Cette page vous a été utile?
0 / 5 - 0 notes