私はここに小さなテストを書きました： https ：
データベースからリクエストすると、MySQLデータベースから2016-04-22T16:00:00.000Z DATETIMEが返されます（最初はデフォルトのUTCタイムゾーンに設定されていますが、ヨーロッパ/ダブリンとしてタイムゾーンとしてテストされています）-つまり、終了日時です私たちのオブジェクトのは、4月22日金曜日の午後4時です。 これは実際にはタイムゾーンがなく、イベントは特定の日付の午後4時に終了する可能性がありますが、その日付はGMTまたはBSTに該当する可能性があります。
提供されたテストでは、現在からその日時までの期間を取得する必要があります。 ただし、常に1時間の休みです。 それを回避する唯一の方法は、日時文字列の末尾から.000Zを削除することです。 また、moment.tzを使用しようとしましたが、同じ結果が得られました（つまり、このテストでは、leftTime4が期待どおりの正しい動作です）。 ただし、leftTime2がそのまま機能することを期待していました。
誰かがこの混乱を解消してくれますか、それとも私はここでバグを見つけていますか？
tanepiper
全てのコメント3件
ISO8601標準では、Zで終わる日付をUTCとして解釈するように指定されています。 そのため、時間が経過したときに何が行われるかは、UTCからローカルに時間を変換することです。 これはあなたがあなたの1時間の休暇の状況を得る方法です。
Zを無視する（時刻をローカルとして解釈する）瞬間が必要な場合は、次のようにして、Zで取得されない形式を指定できます。
moment('2016-04-22T16:00:00.000Z', 'YYYY-MM-DDTHH:mm:ss.SSS').format()
さまざまな解析モードの詳細が必要な場合は、ガイドのこのセクションが役立つ場合があります： http： //momentjs.com/guides/#/parsing/local -utc-zone /
maggiepint
2016年04月19日
そうです、本当の修正は、実際にUTCを意味しない場合は、バックエンドからZを発行しないことです。
mj1856
2016年04月19日
@ mj1856そうしようとしましたが、問題はMySQL自体ではなくSequlizeにあるのではないかと思います。DBに対してクエリを直接実行すると、保存されているYYYY-MM-DD HH：MM：SSの単純なDATETIMEが出力されます。 。 DBのタイムゾーンを変更しても違いはないようです。 とにかく、上記は今のところそれを修正しているようですが、GMTに戻ったときにそれが維持されるかどうかを確認します：bomb：
tanepiper
2016年04月20日
関連する問題
alvarotrigo
·
3コメント
Delgan
·
3コメント
dogukankotan
·
3コメント
RobinvanderVliet
·
3コメント
vbullinger
·
3コメント
最も参考になるコメント
ISO8601標準では、Zで終わる日付をUTCとして解釈するように指定されています。 そのため、時間が経過したときに何が行われるかは、UTCからローカルに時間を変換することです。 これはあなたがあなたの1時間の休暇の状況を得る方法です。
Zを無視する（時刻をローカルとして解釈する）瞬間が必要な場合は、次のようにして、Zで取得されない形式を指定できます。
さまざまな解析モードの詳細が必要な場合は、ガイドのこのセクションが役立つ場合があります： http： //momentjs.com/guides/#/parsing/local -utc-zone /