为什么JSON.NET默认的DateTime序列化改变了？ [英] Why has JSON.NET default DateTime serialization changed?

问题描述

我一直在使用一个旧版本的JSON.Net（4.0r4）一段时间刚刚更新到最新的（4.5r11）。我注意到，日期过去格式如下：

2013-03-20T09：00：00.119Z

但现在是：

2013-03-20T09：00 ：00.119

最后缺少Z。根据维基百科：

如果时间是UTC，则直接在没有空格的时间之前添加一个Z

这已经打破了很多我的JavaScript代码，因为我有一个方法将其转换为一个 DateTime 对象&它希望 Z 。我可以修改这个功能，我用来做这个&我发现我可以
将 DateTimeZoneHandling 设置为 DateTimeZoneHandling.Utc ，但这意味着我会必须在多个项目中更改很多C＃代码。

我只是想知道为什么这会发生变化。

谢谢...

解决方案

你看到这些信息是什么浏览器？由于您实际应对的问题是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内部化日期无关。因为毫秒数字有时候会根据时间来选择一个或两个，如果你传递时间戳，你将会看到随机的失败。

我已经将其报告为Json.Net Codeplex页面上的错误;维护者在错误的评论中被解雇，并被关闭。开源。

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

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

清楚的是，如果没有使用DateTimeKind.UTC，则JSON.Net的部分缺少Z不正确，但它不是一般无效的ISO-8601日期 - 否Z隐含意味着本地时间：

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

如果没有给出时间表示的UTC关系信息，则假定时间在本地时间。

如上所述，Javascript的解析不关心Z，所以为了你的目的，没关系。 p>

请注意，您可能不会将UTC传递到JSON.Net并触发此问题。 C＃中的DateTime对象可以是本地，未指定或UTC 。假设不是UTC的DateTimes实际上是UTC是不公平的;传递没有时区信息是最安全的赌注。 .Net DateTime结构在时区上播放，所以JSON.Net别无选择，只能将默认DateTimes（DateTimeKind.Unspecified）发布为Local，禁止与。Net TimeZone库。

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

but are now:

2013-03-20T09:00:00.119

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

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

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.

Thanks...

解决方案

What browser(s) are you seeing this occur in? Since the issue you're actually coping with is Javascript parsing, in my experience that problem is actually the millisecond rounding, not the presence of a Z or not.

Try this in 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'

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. The second 2 succeed, with and without the Z. What matters is 3 millisecond digits - the Z is irrelevant, including because Javascript does not contain a DateTimeKind like .Net does, so Z or no is irrelevant to how Javascript internalizes the date. Because the number of millisecond digits will sometimes be one or 2 depending on the time, if you're passing timestamps you'll get random-seeming failures.

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.

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

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

To be clear, the lack of a Z is incorrect on JSON.Net's part if it emits without it for DateTimeKind.UTC, but it is not an invalid ISO-8601 date more generally - no Z implicitly means Local Time:

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

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

And as mentioned above Javascript's parsing doesn't care about the Z, so for your purposes, it doesn't matter.

Note also you might not actually be passing UTC to JSON.Net and triggering this issue. 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.

这篇关于为什么JSON.NET默认的DateTime序列化改变了？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！