Pourquoi moment.js UTC affiche-t-il toujours la mauvaise date? Par exemple à partir de la console développeur de Chrome:
moment(('07-18-2013')).utc().format("YYYY-MM-DD").toString()
// or
moment.utc(new Date('07-18-2013')).format("YYYY-MM-DD").toString()
Les deux renverront "2013-07-17" pourquoi revient-il 17ème au lieu de 18ème , qui a été transmis.
Mais si j'utilise momentjs sans utc:
moment(new Date('07-18-2013')).format("YYYY-MM-DD").toString()
Je reçois "2013-07-18", ce que j'attends aussi en utilisant moment.js UTC.
Cela signifie-t-il que nous ne pouvons pas obtenir la date correcte lorsque vous utilisez moment.js UTC?
toString()
aprèsformat()
(il renvoie déjà une chaîne).Réponses:
Par défaut, MomentJS analyse en heure locale. Si seule une chaîne de date (sans heure) est fournie, l'heure par défaut est minuit.
Dans votre code, vous créez une date locale, puis la convertissez en fuseau horaire UTC (en fait, cela fait basculer l'instance du moment en mode UTC ), donc lorsqu'elle est formatée, elle est décalée (en fonction de votre heure locale) vers l'avant ou en arrière.
Si le fuseau horaire local est UTC + N (N étant un nombre positif) et que vous analysez une chaîne de date uniquement, vous obtiendrez la date précédente.
Voici quelques exemples pour l'illustrer (mon décalage horaire local est UTC + 3 pendant l'heure d'été):
Si vous voulez que la chaîne date-heure soit interprétée comme UTC, vous devez être explicite à ce sujet:
ou, comme Matt Johnson le mentionne dans sa réponse, vous pouvez ( et devriez probablement ) l'analyser comme une date UTC en premier lieu en utilisant
moment.utc()
et inclure la chaîne de format comme deuxième argument pour éviter toute ambiguïté.Pour faire l'inverse et convertir une date UTC en date locale, vous pouvez utiliser la
local()
méthode, comme suit:la source
new Date('07-18-2013 UTC')
cela ne fonctionnera pas dans IE8, si vous vous en souciez.Les deux
Date
etmoment
analyseront la chaîne d'entrée dans le fuseau horaire local du navigateur par défaut. CependantDate
est parfois incompatible à cet égard. Si la chaîneYYYY-MM-DD
utilise spécifiquement des traits d'union , ou si c'est le casYYYY-MM-DD HH:mm:ss
, elle l'interprétera comme l'heure locale . Contrairement àDate
,moment
sera toujours cohérent sur la façon dont il analyse.La bonne façon d'analyser un moment d'entrée comme UTC dans le format que vous avez fourni serait comme ceci:
Reportez-vous à cette documentation .
Si vous souhaitez ensuite le formater différemment pour la sortie, procédez comme suit:
Vous n'avez pas besoin d'appeler
toString
explicitement.Notez qu'il est très important de fournir le format d'entrée. Sans cela, une date telle
01-04-2013
que celle du 4 janvier ou du 1er avril pourrait être traitée, en fonction des paramètres de culture du navigateur.la source
moment
sur la console n'est pas très utile. Vous regardez probablement l'une de ses propriétés internes. Vous devez le formater avant de vérifier les résultats. Par exemplemoment.utc().format()
oumoment().format()
.new Date('2010-12-12')
me donneDate {Sat Dec 11 2010 19:00:00 GMT-0500 (Eastern Daylight Time)}
en FF 38.0.5. Juste pour contextualiser ce que «dans l'heure locale» signifie exactement - dans ce cas, cela semble signifier, «Date
supposera qu'une chaîne d'heure sans zone est en UTC et analysera l'heure locale».d.getUTCDate()
=12
andd.getDate()
=11
'2012-12-12'
est UTC b / c c'est au format ISO, mais'December 12, 2012'
et même'2012/12/12'
sont analysés avec un fuseau horaire local dans ES5), mais vous m'avez battu. Tellement génial que ES6 les rend tous locaux [dit-il sarcastiquement]. Les dates sont une douleur, (c) Advent of Dates