我正在使用，它以这种格式返回日期：
/Date(1538245980000-0700)/
它看起来像以毫秒为单位的 Unix 时间戳，后面跟着一个时区。此刻文档声称能够正确处理这些 https://momentjs.com/docs/#/parsing/asp-net-json-date/，但他们也say that https://momentjs.com/docs/#/parsing/asp-net-json-date/
Unix时间戳和Date对象指的是特定的时间点，因此在构造时使用时区偏移量是没有意义的。
根据其他背景（这是周六早上巴士离开斯托尔的时间，距离墨尔本几个小时），我很确定上述时间应该是澳大利亚/墨尔本澳大利亚东部标准时间上午 11:33（+10:00）。
但使用 moment.timezone：
console.log(moment.parseZone('/Date(1538245980000-0700)/').format('h:mma Z'));
"11:33am -07:00"
这看起来确实是错误的：这是指某个时刻：
- 太平洋时间上午 11:33
- 世界标准时间下午 6:33
- 墨尔本时间 4:33 AM
必应错了吗？为什么包含这个时区？
还是我使用Moment的方式不对？在这种情况下，将此格式转换为我的本地时区的正确时间的正确方法是什么？
这就是古时候的“ASP.NET JSON 日期格式 http://momentjs.com/docs/#/parsing/asp-net-json-date/”，由JavaScriptSerializer类（和其他）。斯科特·汉塞尔曼做到了2012 年的一篇博文 https://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx和其他人一样。 （一般来说，现代系统应该更喜欢 ISO 8601 / RFC 3339 格式。）
ASP.NET JSON 日期格式有两部分：
第一部分始终是 Unix 时间戳（以毫秒为单位）。换句话说，自 1970-01-01 00:00:00.000 UTC 以来经过的毫秒数，不考虑闰秒。它不会根据时区进行调整 -它始终基于 UTC.
第二部分是可选的，并且经常被省略。如果存在，它反映时区偏移量should对接收者有意义。但是，它通常是通过序列化生成的DateTime在 .NET 中.Kind财产是DateTimeKind.Local，在这种情况下，它将反映该日期基于server's当地时区。通常该时区是无关紧要的。请注意，与 ISO 8601 不同，基值是not进行调整以反映此偏移量。换句话说，偏移量是无关的。
因此，您给出的时间戳确实代表您列出的值。 （但请注意，墨尔本此时是 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"
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
