我见过很多不同的 JSON 日期格式标准：
"\"\\/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 对日期一无所知。.NET 所做的是非标准的 hack/扩展。
我会使用一种可以轻松转换为DateJavaScript 对象的格式，即可以传递给new Date(...). 最简单且可能最便携的格式是自 1970 年以来包含毫秒的时间戳。
没有正确的格式；JSON 规范没有指定交换日期的格式，这就是为什么有这么多不同的方法可以做到这一点。
最好的格式可以说是以ISO 8601 格式表示的日期（参见 Wikipedia）；它是一种众所周知且广泛使用的格式，可以跨多种不同的语言进行处理，因此非常适合互操作性。如果您对生成的 json 有控制权，例如您以 json 格式向其他系统提供数据，则选择 8601 作为日期交换格式是一个不错的选择。
如果您无法控制生成的 json，例如，您是来自多个不同现有系统的 json 消费者，则处理此问题的最佳方法是使用日期解析实用程序函数来处理预期的不同格式。
I-JSON 代表 Internet JSON 或 Interoperable JSON，具体取决于您询问的对象。
协议通常包含旨在包含时间戳或持续时间的数据项。建议将所有此类数据项表示为 ISO 8601 格式的字符串值，如RFC 3339中所指定，附加限制是使用大写而不是小写字母，不默认包含时区，以及可选的尾随秒数即使它们的值为“00”，也包括在内。还建议所有包含持续时间的数据项都符合 RFC 3339 附录 A 中的“持续时间”产生式，并具有相同的附加限制。
如有疑问，只需按F12（在 Firefox 中为Ctrl+ Shift+ K）进入现代浏览器的 javascript Web 控制台并编写以下内容：
new Date().toISOString()
将输出：
“2019-07-04T13:33:03.969Z”
达达！！
仅供参考，我已经看到使用这种格式：
Date.UTC(2017,2,22)
它适用于该函数支持的JSONP$.getJSON()。不确定我是否会推荐这种方法......只是把它作为一种可能性扔出去，因为人们正在这样做。
FWIW：永远不要在通信协议中使用自纪元以来的秒数，也不要使用自纪元以来的毫秒数，因为由于闰秒的随机实现（您不知道发送方和接收方是否都正确实现了 UTC 闰秒），这些都充满了危险。
有点讨厌，但很多人认为 UTC 只是 GMT 的新名称——错了！如果您的系统没有实现闰秒，那么您使用的是 GMT（尽管不正确，但通常称为 UTC）。如果您确实完全实现了闰秒，那么您确实在使用 UTC。未来的闰秒无法得知；它们会在必要时由 IERS 发布，并且需要不断更新。如果您正在运行的系统尝试实现闰秒但包含过期的参考表（比您想象的更常见），那么您既没有 GMT，也没有 UTC，那么您的系统就会伪装成 UTC。
这些日期计数器仅在以分解格式（y、m、d 等）表示时才兼容。它们从不兼容 epoch 格式。记住这一点。
“2014-01-01T23:28:56.782Z”
日期以标准且可排序的格式表示，该格式表示 UTC 时间（由 Z 表示）。ISO 8601 还通过将 Z 替换为时区偏移的 + 或 – 值来支持时区：
“2014-02-01T09:28:56.321-10:00”
ISO 8601 规范中的时区编码还有其他变体，但 –10:00 格式是当前 JSON 解析器支持的唯一 TZ 格式。一般来说，最好使用基于 UTC 的格式 (Z)，除非您特别需要确定生成日期的时区（仅在服务器端生成中可能）。
注意：
var date = new Date();
console.log(date); // Wed Jan 01 2014 13:28:56 GMT-
1000 (Hawaiian Standard Time)
var json = JSON.stringify(date);
console.log(json); // "2014-01-01T23:28:56.782Z"
告诉你这是首选方式，即使 JavaScript 没有标准格式
// JSON encoded date
var json = "\"2014-01-01T23:28:56.782Z\"";
var dateStr = JSON.parse(json);
console.log(dateStr); // 2014-01-01T23:28:56.782Z
JSON 本身没有日期格式，它不关心任何人如何存储日期。但是，由于这个问题是用 javascript 标记的，我假设您想知道如何在 JSON 中存储 javascript 日期。您可以将日期传递给该JSON.stringify方法，Date.prototype.toJSON默认情况下将使用它，然后使用Date.prototype.toISOString（MDN on Date.toJSON）：
const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object
我还发现，每当我读取 JSON 字符串时，使用（JSON.parse 上reviver的 MDN）的参数自动将 ISO 字符串转换回 javascript 日期很有用。JSON.parse
const isoDatePattern = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);
const obj = {
a: 'foo',
b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);
// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
if (typeof value === 'string' && value.match(isoDatePattern)){
return new Date(value); // isostring, so cast to js date
}
return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...
首选方法是使用2018-04-23T18:25:43.511Z...
下图显示了为什么这是首选方式：
因此，如您所见， Date 有一个本机 Method toJSON，它return采用这种格式并且可以很容易地Date再次转换为......
我相信通用互操作性的最佳格式不是 ISO-8601 字符串，而是 EJSON 使用的格式：
{ "myDateField": { "$date" : <ms-since-epoch> } }
如此处所述：https ://docs.meteor.com/api/ejson.html
好处
结论
我了解人类可读的格式（ISO-8601 字符串）对于 80% 的用例来说是有帮助和更方便的，而且确实不应该告诉任何人不要将他们的日期存储为 ISO-8601 字符串，如果这是他们的应用程序的话理解，但是对于应该保证某些值肯定是日期的普遍接受的传输格式，我们怎么能允许模棱两可并需要如此多的验证？
在 Sharepoint 2013 中，以 JSON 格式获取数据没有将日期转换为仅日期格式的格式，因为该日期应为 ISO 格式
yourDate.substring(0,10)
这可能对你有帮助
解析服务器对我有用
{
"ContractID": "203-17-DC0101-00003-10011",
"Supplier":"Sample Co., Ltd",
"Value":12345.80,
"Curency":"USD",
"StartDate": {
"__type": "Date",
"iso": "2017-08-22T06:11:00.000Z"
}
}
对此只有一个正确答案，而且大多数系统都会出错。自纪元以来的毫秒数，即 64 位整数。时区是一个 UI 问题，在 app 层或 db 层没有业务。为什么你的数据库关心什么是什么时区，当你知道它将把它存储为一个 64 位整数时，然后进行转换计算。
去掉无关的位，将日期视为 UI 上的数字。您可以使用简单的算术运算符来执行查询和逻辑。
以下代码对我有用。此代码将以DD-MM-YYYY格式打印日期。
DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);
否则，您还可以使用：
DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);
我认为这真的取决于用例。在许多情况下，使用适当的对象模型（而不是将日期呈现为字符串）可能更有益，如下所示：
{
"person" :
{
"name" : {
"first": "Tom",
"middle": "M",
...
}
"dob" : {
"year": 2012,
"month": 4,
"day": 23,
"hour": 18,
"minute": 25,
"second": 43,
"timeZone": "America/New_York"
}
}
}
诚然，这比 RFC 3339 更冗长，但是：
Date.toJSON()不支持）我不认为正确的排序（如 funroll 对 RFC 3339 所述）是在将日期序列化为 JSON 时真正需要的功能。这也仅适用于具有相同时区偏移的日期时间。