blocks|key|191860|text|您可以更改序列化DateTime的方式，请从JSON.NET+author：Good+(Date)Times+with+Json.NET查看此内容|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|191861|entityMap|0|LINK|mutability|MUTABLE|url|http://james.newtonking.com/archive/2009/02/20/good-date-times-with-json-net.aspx^0|12|U|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can change how DateTime will be serialized, check this from JSON.NET author: <a href="http://james.newtonking.com/archive/2009/02/20/good-date-times-with-json-net.aspx" rel="nofollow">Good (Date)Times with Json.NET</a>

blocks|key|2818438|text|您在哪个(些)浏览器中看到发生此情况？因为你实际处理的问题是Javascript解析，根据我的经验，这个问题实际上是毫秒级的舍入，而不是Z的存在或不存在。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2818439|在IE9中试试这个：http://jsfiddle.net/b9chris/HaBP8/|offset|length|2818440|'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'|code-block|syntax|javascript|2818441|在大多数浏览器中，所有日期都可以很好地解析；在IE9中，前3个日期无论Z或no都会失败，因为IE9需要毫秒数的3位。第二个2成功了，不管有没有Z。重要的是3毫秒的数字-Z是无关紧要的，包括因为Javascript不像.Net那样包含DateTimeKind，所以Z或否与Javascript如何内化日期无关。因为毫秒数字的数量有时会根据时间的不同而是1或2，如果你正在传递时间戳，你会得到随机的失败。|2818442|I've+reported+this+as+a+bug+on+the+Json.Net+Codeplex+page；它被维护人员在错误的评论中驳回并关闭。去开源吧。|2818443|您可以使用以下答案中的代码解决此错误：|2818444|https://stackoverflow.com/a/15939945/176877|2818445|需要明确的是，如果JSON.Net在没有Z的情况下为DateTimeKind.UTC发出，那么缺少Z是不正确的，但这不是一个无效的ISO-8601日期-没有Z隐含地表示本地时间：|2818446|http://en.wikipedia.org/wiki/ISO_8601#Times|2818447|2818448|如果没有给出带有时间表示的协调世界时关系信息，则假定时间为本地时间。|blockquote|2818449|2818450|2818451|如上所述，Javascript的解析并不关心Z，所以对于您的目的来说，这并不重要。|2818452|另请注意，您实际上可能不会将UTC传递给JSON.Net并触发此问题。C#中的DateTime对象可以是Local,+Unspecified,+or+UTC类型。假设不是协调时的DateTimes实际上是协调时是不公平的；不带时区信息传递它是最安全的选择。.Net+DateTime结构在时区上运行，因此JSON.Net别无选择，只能将默认DateTimes+(DateTimeKind.Unspecified)作为本地发送，从而阻止了与.Net+TimeZone+library的集成。|2818453|entityMap|0|LINK|mutability|MUTABLE|url|http://jsfiddle.net/b9chris/HaBP8/|1|https://json.codeplex.com/workitem/24417|2|3|4|http://msdn.microsoft.com/en-us/library/system.datetime.kind.aspx|5|https://github.com/b9chris/TimeZoneInfoLib.Net^0|0|A|Y|0|0|0|0|0|1L|1|0|0|0|17|2|0|0|0|17|3|0|0|0|0|0|0|1G|Q|4|63|L|5|0^^$0|@$1|2|3|4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1N|8|@]|9|@$D|1O|E|1P|1|1Q]]|A|$]]|$1|F|3|G|5|H|7|1R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|1S|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1T|8|@]|9|@$D|1U|E|1V|1|1W]]|A|$]]|$1|O|3|P|5|6|7|1X|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1Y|8|@]|9|@$D|1Z|E|20|1|21]]|A|$]]|$1|S|3|T|5|6|7|22|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|23|8|@]|9|@$D|24|E|25|1|26]]|A|$]]|$1|W|3|-4|5|6|7|27|8|@]|9|@]|A|$]]|$1|X|3|Y|5|Z|7|28|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|29|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|2A|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2B|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|2C|8|@]|9|@$D|2D|E|2E|1|2F]|$D|2G|E|2H|1|2I]]|A|$]]|$1|16|3|-4|5|6|7|2J|8|@]|9|@]|A|$]]]|17|$18|$5|19|1A|1B|A|$1C|1D]]|1E|$5|19|1A|1B|A|$1C|1F]]|1G|$5|19|1A|1B|A|$1C|R]]|1H|$5|19|1A|1B|A|$1C|V]]|1I|$5|19|1A|1B|A|$1C|1J]]|1K|$5|19|1A|1B|A|$1C|1L]]]]

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: <a href="http://jsfiddle.net/b9chris/HaBP8/" rel="nofollow noreferrer">http://jsfiddle.net/b9chris/HaBP8/</a>

<pre><code>'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'
</code></pre>

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.

<a href="https://json.codeplex.com/workitem/24417" rel="nofollow noreferrer">I've reported this as a bug on the Json.Net Codeplex page</a>; 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:

<a href="https://stackoverflow.com/a/15939945/176877">https://stackoverflow.com/a/15939945/176877</a>

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:

<a href="http://en.wikipedia.org/wiki/ISO_8601#Times" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/ISO_8601#Times</a>

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

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 <a href="http://msdn.microsoft.com/en-us/library/system.datetime.kind.aspx" rel="nofollow noreferrer">Local, Unspecified, or UTC</a>. 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 <a href="https://github.com/b9chris/TimeZoneInfoLib.Net" rel="nofollow noreferrer">.Net TimeZone library</a>.

blocks|key|194080|text|如果服务器上有UTC数据，则应显式设置DateTimeZoneHandling属性|type|unstyled|depth|inlineStyleRanges|entityRanges|data|194081|+//serializer+fix
++++++++config.Formatters.Clear();
++++++++config.Formatters.Add(new+JsonMediaTypeFormatter()
++++++++{
++++++++++++SerializerSettings+=+new+JsonSerializerSettings()+{
++++++++++++++++ContractResolver=new+CamelCasePropertyNamesContractResolver(),
++++++++++++++++DateTimeZoneHandling+=+DateTimeZoneHandling.Utc},

++++++++});|code-block|syntax|javascript|194082|在此之后，DateTime的末尾有"Z“：2017-05-11T00:35:20.8242381Z|offset|length|style|BOLD|194083|entityMap^0|0|0|1C|1|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

If you have UTC data on server you should explicitly set DateTimeZoneHandling property

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

 });
</code></pre>

After this DateTime has "Z" at the end: 2017-05-11T00:35:20.8242381Z

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

<blockquote>
 2013-03-20T09:00:00.119Z
</blockquote>

but are now:

<blockquote>
 2013-03-20T09:00:00.119
</blockquote>

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

<blockquote>
 If the time is in UTC, add a Z directly after the time without a space
</blockquote>

This has broken a lot of my JavaScript code as I have a method that converts this into a <code>DateTime</code> object &amp; it expects the <code>Z</code>. I can fix it by altering this function I use to do this &amp; I've found out that I can 
set the <code>DateTimeZoneHandling</code> to <code>DateTimeZoneHandling.Utc</code> 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...

Why has JSON.NET default DateTime serialization changed?

服务器

JSON

我使用旧版本的JSON.Net (4.0r4)已经有一段时间了，刚刚更新到最新版本(4.5r11)。我注意到过去日期的格式是这样的： 2013-03-20T09:00:00.119Z但现在是： 2013-03-20T09:00:00.119末尾缺少Z。根据维基百科：如果时间以协调世界时为单位，则在时间后面直接添加Z，不...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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