Pourquoi JavaScript Date.getTimezoneOffset () considère-t-il "-05: 00" comme un décalage positif?
J'ai remarqué que pour nous sur le fuseau horaire de l'Est ("America/New_York") avec un décalage de fuseau horaire de "- 05:00" Date.getTimezoneOffset () renvoie un nombre positif de 300. Je m'attendrais à ce que le décalage en minutes soit négatif dans les zones à l'ouest de Utc et positif dans les zones à l'est d'Utc, mais apparemment c'est "retourné". Quel est le raisonnement derrière cette décision?
http://momentjs.com/ suit la même règle et retourne ...
moment.parseZone("01/13/2014 3:38:00 PM +01:00").zone() // == -60
moment.parseZone("01/13/2014 3:38:00 PM -01:00").zone() // == 60
Dans le même temps, DateTimePicker http://trentrichardson.com/examples/timepicker/ ne retourne pas les chiffres lors de la définition de son paramètre initial de "fuseau horaire". Est-ce faux?
Parce que c'est ainsi que cela est défini. Citant le doc ( [~ # ~] mdn [~ # ~] ):
Le décalage de fuseau horaire est la différence, en minutes, entre l'heure UTC et l'heure locale. Notez que cela signifie que le décalage est positif si le fuseau horaire local est derrière UTC et négatif s'il est devant .
Élaborer un peu sur la réponse parfaitement acceptable de raina77ow ...
Tout d'abord, comprenez que les principales normes impliquées ici sont ISO 8601 et RFC 822 (et ses apparentés 7 , 112 & 2822 ), qui étaient tous (en partie) dérivés de ANSI X3.51-1975.
Toutes ces normes utilisent la convention des valeurs positives étant à l'est de UTC/GMT et les valeurs négatives étant à l'ouest de UTC/GMT.
La seule norme que je connaisse qui a inversé est POSIX (voir la section POSIX de le wiki du tag de fuseau horaire , et cet article ), et explique donc pourquoi le compatibilité Les fuseaux horaires Olson comme "Etc/GMT + 5" ont leur signe inversé. (Bien sûr, il est possible qu'il existe d'autres usages et je ne les connais pas.)
Croyez-le ou non, JavaScript le fait DES DEUX façons. Lorsqu'il est utilisé en tant que chaîne (dans la syntaxe RFC 822 ou ISO 8601), il utilise les heures et les minutes avec des décalages positifs Est UTC. Mais lors de l'appel de la méthode getTimezoneOffset() sur l'objet Date, elle renvoie des minutes entières positives Ouest UTC .
On ne peut que spéculer sur la raison de cette incohérence. Le spécification ECMAScript est plein de problèmes comme celui-ci. C'est peut-être parce que lorsque vous voyez un décalage dans une chaîne ISO 8601 ou RFC 822, ce décalage a déjà appliqué. Mais lorsque vous appelez getTimezoneOffset() c'est l'offset à appliqué pour le ramener à UTC.
Par exemple, 2014-01-01T00:00:00-05:00 Est égal à 2014-01-01T05:00:00Z. Donc getTimezoneOffset() retournerait 300. Si vous ajoutez 300 minutes à la valeur d'origine, vous revenez à UTC.
C'est deux faces d'une même pièce. Voir?
Quant à savoir si ce contrôle spécifique est incorrect ou non, je ne suis pas sûr. Je ne connais pas ce contrôle particulier. Je vois dans leurs documents l'exemple de -0400 égal à -240, que l'on pourrait s'attendre à inverser, mais là encore, c'est un peu étrange d'avoir une valeur comme -240 présentée à un utilisateur. Vraiment, vous ne devez pas exposer les compensations à un utilisateur dans un sens ou dans l'autre (IMHO). Il vaut mieux utiliser un contrôle de sélection de fuseau horaire, comme celui-ci ou celui-ci .