“正确”的JSONdate格式
我已经看到JSONdate格式有很多不同的标准：
"\"\\/Date(1335205592410)\\/\"" .NET JavaScriptSerializer "\"\\/Date(1335205592410-0500)\\/\"" .NET DataContractJsonSerializer "2012-04-23T18:25:43.511Z" JavaScript built-in JSON object "2012-04-21T18:25:43-05:00" ISO 8601 哪一个是正确的？ 还是最好？ 这有什么标准吗？
JSON本身并没有指定如何表示date，但JavaScript。
你应该使用Date的toJSON方法发出的格式：
2012-04-23T18:25:43.511Z
原因如下：
-
它是人类可读的，但也简洁
-
它sorting正确
-
它包括小数秒，这可以帮助重build年表
-
它符合ISO 8601
-
ISO 8601在国际上已经有十多年的历史
-
ISO 8601得到了W3C ， RFC3339和XKCD的认可
也就是说 ，每个写过的date库都能理解“1970年以来的毫秒”。 所以为了便于携带，ThiefMaster是正确的。
JSON不知道有关date的任何信息。 .NET所做的是一个非标准的破解/扩展。
我将使用一种格式，可以很容易地在JavaScript中转换为一个Date对象，即可以传递给new Date(...) 。 最简单也是最便携的格式是自1970年以来包含毫秒的时间戳。
没有正确的格式 ; JSON规范没有规定交换date的格式，这就是为什么有很多不同的方式来做到这一点。
最好的格式可以说是以8601格式表示的date ; 它是一个众所周知和广泛使用的格式，可以跨多种不同的语言进行处理，使其非常适合于互操作性。 例如，如果您可以控制生成的json，则可以使用json格式向其他系统提供数据，select8601作为date交换格式是个不错的select。
例如，如果您不能控制生成的json，那么您就是来自多个不同现有系统的json的使用者，处理这个问题的最佳方法是使用dateparsing实用程序函数来处理预期的不同格式。
从RFC 7493（I-JSON消息格式） ：
I-JSON代表互联网JSON或可互操作的JSON，具体取决于你问的对象。
协议通常包含旨在包含时间戳或持续时间的数据项。 build议将所有这样的数据项以ISO 8601格式的string值表示，如RFC 3339中所规定的那样，并且附加的限制是使用大写字母而不是小写字母，包括非默认时区，以及可选的结尾秒数即使当它们的值是“00”时也被包括在内。 还build议所有包含持续时间的数据项目符合RFC 3339附录A中的“持续时间”生产，并具有相同的附加限制。
仅供参考，我已经看到使用这种格式：
Date.UTC(2017,2,22)
它使用$.getJSON()函数支持的JSONP 。 不知道我会推荐这种方法，只是把它扔到那里，因为人们这样做。
FWIW：永远不要在通讯协议中使用秒数，也不要使用自纪元以来的毫秒数，因为随机执行闰秒（您不知道发送者和接收者是否正确实现了UTC闰秒），这些都是危险的。
一种宠物讨厌，但很多人认为，UTC只是GMT的新名字 – 错了！ 如果你的系统没有实现闰秒，那么你正在使用GMT（通常称为UTC，尽pipe是不正确的）。 如果你完全实现了闰秒你真的使用UTC。 未来的闰秒是不可知的; 他们会根据需要发布IERS，并要求不断更新。 如果你正在运行一个试图实现闰秒但包含过期参考表（比你想象的更为常见）的系统，那么你既没有GMT也没有UTC，你有一个伪装成UTC的系统。
这些date计数器仅在以分解格式（y，m，d等）表示时才兼容。 它们从来不以时代格式兼容。 记住这一点。
对此只有一个正确的答案，大多数系统错误。 历元以来的毫秒数，又称64位整数。 时区是一个用户界面的问题，在应用层或数据库层没有业务。 为什么你的数据库关心的是什么时区，当你知道它将存储为一个64位整数，然后做转换计算。
去除多余的位，并将date视为数字直到UI。 您可以使用简单的算术运算符来执行查询和逻辑。
在Sharepoint 2013中，在JSON中获取数据没有格式将date转换为date格式，因为在那个date应该是ISO格式
yourDate.substring(0,10)
这可能对你有帮助
这是parsing服务器为我工作
{“ContractID”：“203-17-DC0101-00003-10011”，“供应商”：“Sample Co.，Ltd”，“Value”：12345.80，“Curency”：“USD”，“StartDate”：{“__type “：”Date“，”iso“：”2017-08-22T06：11：00.000Z“}}
我认为这取决于用例。 在许多情况下，使用适当的对象模型（而不是将date呈现为string）可能更有利，如下所示：
{ "year": 2012, "month": 4, "day": 23, "hour": 18, "minute": 25, "second": 43, "timeZone": "America/New_York" }
无可否认，这比RFC 3339更详细，但是：
- 它也是人类可读的
- 它实现了一个适当的对象模型（就像在OOP中，就JSON所允许的那样）
- 它支持时区（不仅在给定的date和时间的UTC偏移量）
- 它可以支持更小的单位，如毫秒，纳秒，或者仅仅是小数秒
- 它不需要单独的parsing步骤（parsingdate时间string），JSONparsing器将为您做所有事情
- 用任何语言简单创build任何date时间框架或实现
- 可以很容易地扩展到支持其他日历尺度（希伯来文，中文，伊斯兰教…）和时代（AD，BC，…）
- 它是10000年的安全;-)（RFC 3339是不）
- 支持全天date和浮动时间（Javascript的
Date.toJSON()不）
我不认为正确的sorting（正如RFC 3339的funroll所指出的）是在将date序列化到JSON时真正需要的function。 对于具有相同时区偏移的date时间也是如此。
