我期待什么

我有节点应用程序，可以向Facebook Messenger等平台发送广播。用户订阅在设定的时间接收广播，例如每天下午2点。

用户使用字段nextQuoteDate保存到数据库，其中Date对象值已修改为具有应用程序需要发送下一个广播的确切时间，例如2018-03-29T14:00:00.000Z。因此，应用程序会检查用户是否广播到例如user.find({ nextQuoteData: {$lte: new Date()} })如果广播已发送，则此字段会额外获得一天：2018-03-30T14:00:00.000Z。

我现在看到的是什么

在夏令时之后，我的所有节点应用程序现在都会在一小时后发送广播。所以不是下午2点，而是下午3点。这是因为当我期待2018-03-29T13:37:48.508Z时，新的Date（）会返回2018-03-29T14:37:48.508Z。

这是我一直在玩的，试图理解这一点。

me$ date
Thu 29 Mar 2018 14:37:39 BST
me$ node
> Date()
'Thu Mar 29 2018 14:37:45 GMT+0100 (BST)'
> new Date()
2018-03-29T13:37:48.508Z
> new Date().toLocaleString()
'2018-3-29 14:38:02'
> new Date(new Date().toLocaleString())
2018-03-29T13:38:10.000Z
> new Date(new Date().toLocaleString() + ' GMT')
2018-03-29T14:38:15.000Z

但还没有解决方案。有什么建议吗？

Answer 1

它们不会落后一小时。

Thu 29 Mar 2018 14:37:39 BST

英国夏令时2.37pm

＆＃39; Thu Mar 29 2018 14:37:45 GMT + 0100（BST）＆＃39;

英国夏令时2.37pm

2018-03-29T13：37：48.508Z

1.37 pm UCT比BST落后一小时是正确的

＆＃39; 2018-3-29 14：38：02＆＃39;

2.38pm，没有指定的时区（但你要求的是Locale Time，这将是BST）

2018-03-29T13：38：10.000Z

1.38 pm UCT比BST落后一小时是正确的

2018-03-29T14：38：15.000Z

2.38pm UCT比BST落后一小时，这是错误的，因为你把错误的时区砍成了字符串。

将时间戳转换为UCT是非常正常的事情。它允许以一致的方式处理它们。

您可能希望避免显式格式化它们（例如使用toLocaleString）以显示给人类，但这并不是Date对象的工作原理，因此您必须忍受它

Answer 2

最后查看Z？这表示零小时偏移。输出只是标准化为0偏移的日期 - 这是一个国际化的事情 - JavaScript实际上是正确的并允许这样做。

为什么夏令时后JavaScript日期不会更新？

我期待什么

我现在看到的是什么

2 个答案: