您在哪些浏览器中看到这种情况?由于您实际处理的问题是 Javascript 解析,因此根据我的经验,该问题实际上是毫秒舍入,而不是 Z 的存在与否。
在 IE9 中试试这个:http: //jsfiddle.net/b9chris/HaBP8/
'2013-06-13T20:43:55.6',
'2013-06-13T20:43:55.61',
'2013-06-13T20:43:55.61Z',
'2013-06-13T20:43:55.611',
'2013-06-13T20:43:55.611Z'
在大多数浏览器中,所有日期都可以解析;在 IE9 中,前 3 个失败,无论 Z 或否,因为 IE9 需要 3 个位置的毫秒数。第二个 2 成功,有和没有 Z。重要的是 3 毫秒数字 - Z 无关紧要,包括因为 Javascript 不包含像 .Net 那样的 DateTimeKind,所以 Z 与否与 Javascript 如何内化日期无关。因为毫秒位数有时会是 1 或 2,具体取决于时间,如果您传递时间戳,您将获得看似随机的失败。
我在 Json.Net Codeplex 页面上将此报告为错误;它在错误的评论中被维护者驳回并关闭。去开源。
您可以使用此答案中的代码解决此错误:
https://stackoverflow.com/a/15939945/176877
需要明确的是,如果 JSON.Net 没有为 DateTimeKind.UTC 发出它,则缺少 Z 是不正确的,但更一般地说,它不是无效的 ISO-8601 日期 - 没有 Z 隐含表示当地时间:
http://en.wikipedia.org/wiki/ISO_8601#Times
如果没有给出带有时间表示的 UTC 关系信息,则假定时间为本地时间。
并且如上所述,Javascript 的解析并不关心 Z,因此对于您的目的而言,这并不重要。
另请注意,您可能实际上并未将 UTC 传递给 JSON.Net 并触发此问题。C# 中的 DateTime 对象可以是Local、Unspecified 或 UTC类型。假设不是 UTC 的 DateTimes 实际上是 UTC 是不公平的。在没有时区信息的情况下传递它是最安全的选择。.Net DateTime 结构以时区为基础,因此 JSON.Net 别无选择,只能将默认 DateTimes (DateTimeKind.Unspecified) 作为本地发出,除非与.Net TimeZone 库集成。