Moment: Confusion sur moment.utz avec MySQL DateTime

Créé le 18 avr. 2016 · 3Commentaires · Source: moment/moment

J'ai écrit un petit test ici : https://jsfiddle.net/vrdhcuey/1/

Lorsque nous demandons à la base de données, nous récupérons un DATETIME de la base de données MySQL (initialement défini sur le fuseau horaire UTC par défaut mais également testé avec le fuseau horaire Europe/Dublin) de 2016-04-22T16:00:00.000Z - c'est-à-dire la date et l'heure de fin de notre objet est le vendredi 22 avril, à 16h. C'est en réalité sans fuseau horaire car tout ce que nous disons, c'est que l'événement peut se terminer à 16 heures à une date donnée, mais cette date pourrait tomber en GMT ou BST.

Dans le test fourni, nous voulons obtenir la durée entre maintenant et cette date-heure. Cependant, il est toujours une heure de congé. Le seul moyen de contourner cela est de supprimer le .000Z à la fin de la chaîne datetime. J'ai également essayé d'utiliser moment.tz mais j'ai le même résultat (c'est-à-dire que dans ce test, leftTime4 est le comportement correct auquel nous nous attendons). Je me serais cependant attendu à ce que leftTime2 fonctionne tel quel.

Quelqu'un peut-il dissiper cette confusion, ou est-ce que je rencontre un bogue ici?

Source

tanepiper

Commentaire le plus utile

La norme ISO8601 spécifie que les dates se terminant par Z doivent être interprétées comme UTC. En tant que tel, le moment où votre temps est passé est de convertir l'heure de l'UTC en local. C'est ainsi que vous obtenez votre situation d'une heure de congé.

Si vous souhaitez momentanément ignorer le Z (interpréter l'heure comme locale), vous pouvez spécifier un format qui ne capte pas le Z en procédant comme suit :

moment('2016-04-22T16:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSS').format()

Si vous souhaitez plus d'informations sur les différents modes d'analyse, cette section des guides peut vous être utile : http://momentjs.com/guides/#/parsing/local -utc-zone/

maggiepint le 19 avr. 2016

👍2

Tous les 3 commentaires

Si vous souhaitez momentanément ignorer le Z (interpréter l'heure comme locale), vous pouvez spécifier un format qui ne capte pas le Z en procédant comme suit :

moment('2016-04-22T16:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSS').format()

Si vous souhaitez plus d'informations sur les différents modes d'analyse, cette section des guides peut vous être utile : http://momentjs.com/guides/#/parsing/local -utc-zone/

maggiepint le 19 avr. 2016

👍2

Bon - donc, la vraie solution est de ne pas émettre de Z depuis votre back-end si vous ne voulez pas vraiment dire UTC.

mj1856 le 19 avr. 2016

😄1

@ mj1856 Oui, j'ai essayé, mais je me demande si le problème vient de Sequlize plutôt que de MySQL lui-même - lorsque nous exécutons la requête directement sur la base de données, il émet simplement un DATETIME simple avec AAAA-MM-JJ HH:MM:SS, car il est stocké . Changer le fuseau horaire de la base de données ne semblait faire aucune différence. Quoi qu'il en soit, ce qui précède semble résoudre le problème pour le moment, nous verrons si cela tient le coup lorsque nous reviendrons en GMT :bomb:

tanepiper le 20 avr. 2016

Cette page vous a été utile?

0 / 5 - 0 notes