如何使用Moment正确处理Bing中的“/ Date（... -0700）/”日期格式？

Question

我正在使用Bing Routes API，它以这种格式返回日期：

/Date(1538245980000-0700)/

它看起来像Unix时间戳，以毫秒为单位，后跟一个时区。片刻文件claim to be able to handle these correctly，但他们也say that

Unix时间戳和Date对象是指特定的时间点，因此在构造时使用时区偏移是没有意义的。

根据其他情况（这是公共汽车离开Stawell的时间，距离墨尔本，周六早上几个小时），我很确定上述时间应该是澳大利亚/墨尔本AEST（+10：00）上午11:33。

但是使用moment.timezone：

console.log(moment.parseZone('/Date(1538245980000-0700)/').format('h:mma Z'));

"11:33am -07:00"

这似乎是错误的：这指的是一个时刻，即：

• 太平洋时间上午11:33，
• UTC时间下午6:33
• 墨尔本时间凌晨4:33

Bing错了吗？为什么包含这个时区？

还是我使用Moment错了？在这种情况下，使用我的本地时区将此格式转换为正确时间的正确方法是什么？

Answer 1

这是由ASP.NET JSON Date Format班（和其他人）制作的过时的“JavaScriptSerializer”。和其他人一样，斯科特汉塞尔曼对其进行了a blog post back in 2012。 （通常，现代系统应该更喜欢ISO 8601 / RFC 3339格式。）

ASP.NET JSON日期格式包含两部分：

• 第一部分始终是Unix时间戳，以毫秒为单位。换句话说，自1970-01-01 00：00：00.000 UTC以来经过的毫秒数，不考虑闰秒。它不会针对时区进行调整 - 它始终基于UTC。
• 第二部分是可选的，经常被省略。当存在时，它反映了对接收器有意义的时区偏移。但是，它通常是通过序列化.NET中的DateTime生成的，其.Kind属性为DateTimeKind.Local，在这种情况下，它将根据服务器的本地时区反映该日期的时区偏移量。通常那个时区是无关紧要的。请注意，与ISO 8601不同，不会调整基值以反映此偏移。换句话说，偏移是无关紧要的。

因此，您给出的时间戳确实代表您列出的值。 （虽然注意墨尔本目前是UTC + 10，而不是UTC + 11.）

关于Moment，请记住，parseZone旨在将moment对象的时区偏移设置为输入中提供的时间偏移（在本例中为-0700）。如果您不关心该偏移量，那么您可以使用任何其他解析函数：

moment.parseZone('/Date(1538245980000-0700)/').format()
//=> "2018-09-29T11:33:00-07:00"  (always)

moment('/Date(1538245980000-0700)/').format()
//=> "2018-09-29T14:33:00-04:00"  (example based on the local time zone being US Eastern time)

moment.utc('/Date(1538245980000-0700)/').format()
//-> "2018-09-29T18:33:00Z"       (always, since parsing as UTC)

moment.tz('/Date(1538245980000-0700)/', 'Australia/Melbourne').format()
//=> "2018-09-30T04:33:00+10:00"  (always - since time zone provided)

在上面的所有例子中，只有在第一个例子中才使用-0700。

所以 - 如果你期望价值代表墨尔本的时间，那么是 - Bing是错误的。也许还有一些其他设置或方面要考虑的数据。或许这是一个错误，如果是这样你应该报告它。

如果是这样，你需要补偿，那么这样做：

moment.parseZone('/Date(1538245980000-0700)/').tz('Australia/Melbourne', true).format()
//=> "2018-09-29T11:33:00+10:00"