为什么 IE/FF 和 Chrome 需要 JavaScript 引擎解释方式不同 this 日期格式 (YYYY-MM-DDTHH:mm:ss.fff) 没有时区指示符？
new Date("2015-02-18T15:43:57.803").getUTCHours()
世界标准时间
Chrome: 15
IE11/FF: 21
我不明白这一点 - 是因为 Chrome 假定它是本地的，而 IE/FF 假定它是 UTC 吗？这似乎是一个 Chrome 错误。
有趣的是 - 在字符串末尾附加一个“Z”告诉 Chrome 和 IE/FF 时间是 UTC 并且他们可以同意。有没有其他人注意到这个 javascript 实现差异Date?
new Date("2015-02-18T15:43:57.803Z").getUTCHours()
世界标准时间
Chrome: 15
IE11/FF: 15
最终——这就是结果适用于 ASP.NET Web API 的开箱即用序列化器，我以为使用了 JSON.NET，但现在似乎是 JSON.NET 使用的内部IsoDateTimeConverter.
检查GlobalConfiguration.Configuration.Formatters.JsonFormatter告诉我我们正在使用JsonMediaTypeFormatter。 Web API 是否不使用开箱即用的 JSON.NET 序列化器？
这对于 Web API 人员来说是一个福音 - 至少在 ASP.NET MVC 中我们有一致的日期格式（尽管是专有的 -/日期（刻度数）/
ES5表示没有时区的 ISO 8601 格式日期应被视为本地日期（该解释此后已被修订），但是编辑。 6 草稿说将它们视为 UTC。一些脚本引擎已经实现了 ed。 6、一些 ES5，其余则不然。
编辑。 6（及更高版本）与 ISO 8601 规范不一致。
底线是不要使用日期解析（或将字符串传递给 Date 构造函数），手动解析日期字符串。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
