我使用旧版本的JSON.Net (4.0r4)已经有一段时间了,刚刚更新到最新版本(4.5r11)。我注意到过去日期的格式是这样的:
2013-03-20T09:00:00.119Z
但现在是:
2013-03-20T09:00:00.119
末尾缺少Z。根据维基百科:
如果时间以协调世界时为单位,则在时间后面直接添加Z,不带空格
这破坏了我的很多JavaScript代码,因为我有一个方法可以将它转换为一个DateTime
对象&它需要Z
。我可以通过修改这个函数来解决这个问题&我发现可以将DateTimeZoneHandling
设置为DateTimeZoneHandling.Utc
,但这意味着我必须在多个项目中更改大量的C#代码。
我只是想知道为什么这种情况会改变。
谢谢..。
发布于 2013-06-19 11:31:09
您在哪个(些)浏览器中看到发生此情况?因为你实际处理的问题是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的集成。
发布于 2013-04-03 22:29:47
您可以更改序列化DateTime的方式,请从JSON.NET author:Good (Date)Times with Json.NET查看此内容
发布于 2017-05-13 09:57:38
如果服务器上有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
https://stackoverflow.com/questions/15520717
复制相似问题