我在这里写了一个小测试： https :
当我们从数据库请求时，我们会从 MySQL 数据库中获得2016-04-22T16:00:00.000Z的 DATETIME（最初设置为默认的 UTC 时区，但也将其设置为欧洲/都柏林时区进行了测试） - 即结束日期时间我们的对象是 4 月 22 日星期五下午 4 点。 这实际上是无时区的，因为我们所说的是活动可以在给定日期的下午 4 点结束，但该日期可能落在格林威治标准时间或英国夏令时。
在提供的测试中，我们想要获得现在和那个日期时间之间的持续时间。 然而，它总是休息一个小时。 解决它的唯一方法是从日期时间字符串的末尾删除.000Z 。 我也尝试使用 moment.tz 但有相同的结果（即在这个测试中 leftTime4 是我们期望的正确行为）。 然而，我本来希望 leftTime2 按原样工作。
任何人都可以澄清这种困惑，还是我在这里遇到了错误？
tanepiper
所有3条评论
ISO8601 标准规定以 Z 结尾的日期应解释为 UTC。 因此，当您的时间过去时，将时间从 UTC 转换为本地时间。 这就是你如何摆脱一小时的情况。
如果您希望暂时忽略 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是的，但我想知道问题是否出在 Sequlize 而不是 MySQL 本身 - 当我们直接对数据库运行查询时，它只发出一个带有 YYYY-MM-DD HH:MM:SS 的普通 DATETIME，因为它是存储的. 更改数据库的时区似乎没有任何区别。 无论如何，上面似乎暂时修复了它，当我们回到格林威治标准时间时，我们将看看它是否能坚持下去：bomb：
tanepiper
于 2016-04-20
相关问题
dogukankotan
·
3评论
BonBonSlick
·
3评论
BCup
·
3评论
IbraheemAlSaady
·
3评论
benhathaway
·
3评论
最有用的评论
ISO8601 标准规定以 Z 结尾的日期应解释为 UTC。 因此，当您的时间过去时，将时间从 UTC 转换为本地时间。 这就是你如何摆脱一小时的情况。
如果您希望暂时忽略 Z（将时间解释为本地时间），您可以通过执行以下操作来指定不接收 Z 的格式：
如果您想了解有关各种解析模式的更多信息，指南的这一部分可能会有所帮助： http ://momentjs.com/guides/#/parsing/local -utc-zone/