问为什么JSON.NET默认的DateTime序列化发生了变化？

EN

您在哪个(些)浏览器中看到发生此情况？因为你实际处理的问题是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或no都会失败，因为IE9需要毫秒数的3位。第二个2成功了，不管有没有Z。重要的是3毫秒的数字-Z是无关紧要的，包括因为Javascript不像.Net那样包含DateTimeKind，所以Z或否与Javascript如何内化日期无关。因为毫秒数字的数量有时会根据时间的不同而是1或2，如果你正在传递时间戳，你会得到随机的失败。

I've reported this as a bug on the Json.Net Codeplex page；它被维护人员在错误的评论中驳回并关闭。去开源吧。

您可以使用以下答案中的代码解决此错误：

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

需要明确的是，如果JSON.Net在没有Z的情况下为DateTimeKind.UTC发出，那么缺少Z是不正确的，但这不是一个无效的ISO-8601日期-没有Z隐含地表示本地时间：

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

如果没有给出带有时间表示的协调世界时关系信息，则假定时间为本地时间。

如上所述，Javascript的解析并不关心Z，所以对于您的目的来说，这并不重要。

另请注意，您实际上可能不会将UTC传递给JSON.Net并触发此问题。C#中的DateTime对象可以是Local, Unspecified, or UTC类型。假设不是协调时的DateTimes实际上是协调时是不公平的；不带时区信息传递它是最安全的选择。.Net DateTime结构在时区上运行，因此JSON.Net别无选择，只能将默认DateTimes (DateTimeKind.Unspecified)作为本地发送，从而阻止了与.Net TimeZone library的集成。

您可以更改序列化DateTime的方式，请从JSON.NET author：Good (Date)Times with Json.NET查看此内容

如果服务器上有UTC数据，则应显式设置DateTimeZoneHandling属性

 //serializer fix
        config.Formatters.Clear();
        config.Formatters.Add(new JsonMediaTypeFormatter()
        {
            SerializerSettings = new JsonSerializerSettings() {
                ContractResolver=new CamelCasePropertyNamesContractResolver(),
                DateTimeZoneHandling = DateTimeZoneHandling.Utc},

        });

在此之后，DateTime的末尾有"Z“：2017-05-11T00:35:20.8242381Z