如何正确处理"/Date(...- 0700)/"使用Bing从Bing中获取日期格式? [英] How to correctly handle "/Date(...-0700)/" date format from Bing using Moment?

问题描述

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

I'm using the Bing Routes API, and it's returning dates in this kind of format:

/Date(1538245980000-0700)/

它看起来像Unix时间戳(以毫秒为单位)，后跟一个时区. Moment文档声称能够正确处理这些问题 ，但他们也说

It looks like Unix timestamp in milliseconds, followed by a timezone. The Moment docs claim to be able to handle these correctly, but they also say that

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

Unix timestamps and Date objects refer to specific points in time, thus it doesn't make sense to use the time zone offset when constructing.

基于其他情况(这是星期六星期六早上从墨尔本离开斯塔维尔的公共汽车的时间，距离墨尔本几个小时)，我很确定上述时间应该是澳大利亚/墨尔本AEST的上午11:33(+10: 00).

Based on other context (it's the time a bus leaves Stawell, a few hours from Melbourne, on Saturday morning), I'm pretty sure that the above time should be 11:33AM in Australia/Melbourne AEST (+10:00).

但是使用moment.timezone:

But using moment.timezone:

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

"11:33am -07:00"

这似乎确实是错误的:这是指某个时刻:

That seems really wrong: this is referring to a moment in time which is:

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

Bing错了吗?为什么要包含该时区?

Is Bing wrong? Why is this timezone included?

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

Or am I using Moment wrong? In which case, what is the correct way to convert this format into the correct time with my local timezone?

推荐答案

这是过时的" ASP.NET JSON日期格式"，由JavaScriptSerializer类(和其他类)生成.斯科特·汉塞尔曼(Scott Hanselman)和其他人一样，在 2012年写了一篇博客文章. (通常，现代系统应改用ISO 8601/RFC 3339格式.)

This is the antiquated "ASP.NET JSON Date Format", produced by the JavaScriptSerializer class (and others). Scott Hanselman did a blog post back in 2012 on it, as have others. (Generally, modern systems should prefer the ISO 8601 / RFC 3339 format instead.)

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

The ASP.NET JSON date format has two parts:

• 第一部分始终是Unix时间戳(以毫秒为单位).换句话说，自1970-01-01 00:00:00.000 UTC以来经过的毫秒数，未考虑leap秒.它不会针对时区进行调整-始终基于UTC .

第二部分是可选的，并且经常被省略.当存在时，它反映出时域偏移量，应该对接收者有意义.但是，通常是通过在.NET中将其.Kind属性为DateTimeKind.Local的.c中的DateTime序列化来生成的，在这种情况下，它将根据服务器的本地反映该日期的时区偏移量.时区.通常，该时区是无懈可击的.请注意，与ISO 8601不同，对基值进行了 not 调整以反映此偏移. 换句话说，偏移量是多余的.

The second part is optional, and often ommited. When present, it reflects a time zone offset that should be meaningful to the receiver. However, it is usually generated by serializing a DateTime in .NET whose .Kind property is DateTimeKind.Local, in which case it will reflect the time zone offset for that date based on the server's local time zone. Often that time zone is irrelavent. Note that unlike ISO 8601, the base value is not adjusted to reflect this offset. In other words, the offset is extraneous.

因此，您提供的时间戳确实代表您列出的值. (不过请注意，墨尔本目前是UTC + 10，而不是UTC + 11.)

Thus, the timestamp you gave indeed represents the values you listed. (Though note that Melbourne is UTC+10 at this time, not UTC+11.)

关于矩，请记住，parseZone旨在将力矩对象的时区偏移设置为输入中提供的偏移(在本例中为-0700).如果您不关心该偏移量，则可以使用任何其他解析函数:

With regard to Moment, keep in mind that parseZone is intended to set the time zone offset of the moment object to the one provided in the input (-0700 in this case). If you don't care about that offset, then you can use any of the other parsing functions:

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.

In all the above examples, only in the first one was the -0700 used at all.

所以-如果您希望该值代表墨尔本的时间，那么可以-Bing错误.数据可能还有其他设置或方面需要考虑.也许这是一个错误，如果是的话，您应该这样报告.

So - if you expected the value to represent the time in Melbourne, then yes - Bing is wrong. Perhaps there is some other setting or aspect to the data to consider. Or perhaps it's a bug and if so you should report it as such.

如果是这样，并且您需要补偿，则请执行以下操作:

If so, and you need to compensate, then do this:

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

这篇关于如何正确处理"/Date(...- 0700)/"使用Bing从Bing中获取日期格式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！