我已经使用了一段时间和放的是旧版本JSON.Net（4.0r4）的;刚刚更新到最新版本（4.5r11）。我注意到，使用日期的格式，如：

I've been using an old version of JSON.Net (4.0r4) for a while & have just updated to the latest one (4.5r11). I've noticed that dates used to be formatted like:

2013-03-20T09：00：00.119Z

2013-03-20T09:00:00.119Z

但现在：

2013-03-20T09：00：00.119

2013-03-20T09:00:00.119

的Z被丢失在末端。根据维基百科：

The Z is missing at the end. According to Wikipedia:

如果时间是UTC的时间后直接加为Z没有空格

If the time is in UTC, add a Z directly after the time without a space

这打破了很多我的JavaScript code，因为我有这一切都使这成为一个的DateTime 物体放方法;它期望以Z 。我可以改变这个功能我用它来做到这一点和放大器解决它;我发现了，我可以 设置 DateTimeZoneHandling 到 DateTimeZoneHandling.Utc 但这意味着我将不得不改变很多C＃code在多个项目。

This has broken a lot of my JavaScript code as I have a method that converts this into a DateTime object & it expects the Z. I can fix it by altering this function I use to do this & I've found out that I can set the DateTimeZoneHandling to DateTimeZoneHandling.Utc but this means I would have to change a lot of C# code in multiple projects.

我只是想知道，为什么这种情况已经改变。

I'm just wondering why this has changed.

谢谢...

推荐答案

什么浏览器（S），你看到这种情况发生吗？我相信这个问题实际上是毫秒级的舍入，而不是一个z的presence与否。

What browser(s) are you seeing this occur in? I believe the problem is actually the millisecond rounding, not the presence of a Z or not.

在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个地方的毫秒数。如果你传递时间戳你会得到随机似乎失效。

In most browsers all dates parse fine; in IE9 the first 3 fail, regardless of a Z or no, because IE9 requires 3 places for the milliseconds number. If you're passing timestamps you'll get random-seeming failures.

我报这个作为Json.Net codePLEX页错误;它被驳回的缺陷和关闭的意见维护者。去开源。

I've reported this as a bug on the Json.Net Codeplex page; it was dismissed by the maintainer in the comments of the bug and closed. Go open source.

您可以解决此错误使用code。在这样的回答：

You can work around this bug using the code in this answer:

http://stackoverflow.com/a/15939945/176877

为Z的缺乏似乎是正确的行为 - 它含蓄地意味着本地时间：

The lack of a Z appears to be correct behavior - it implicitly means Local Time:

http://en.wikipedia.org/wiki/ISO_8601#Times

如果没有UTC关系信息给出用时间重新presentation，时间被假定为在本地时间

If no UTC relation information is given with a time representation, the time is assumed to be in local time.

在C＃的DateTime对象可以是一种地方，未指定，或UTC 的。这是不公平的假设，DateTime是否不属于UTC事实上UTC;通过它没有时区信息是最安全的赌注。在.NET DateTime的结构平底船上时区，所以JSON.Net是别无选择，只能发出默​​认创建DateTime对象（DateTimeKind.Unspecified）作为本地，除非集成了的。净时区图书馆。

DateTime objects in C# can be of kind Local, Unspecified, or UTC. It's not fair to assume that DateTimes that aren't UTC are in fact UTC; passing it without timezone information is the safest bet. The .Net DateTime structure punts on timezones, so JSON.Net is left with no choice but to emit default DateTimes (DateTimeKind.Unspecified) as Local, barring integration with a .Net TimeZone library.