什么是“正确”的 JSON 日期格式？

IT技术 javascript json
2021-01-17 03:56:45

我见过很多不同的 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

哪一个是正确的？还是最好？这有什么标准吗？

6个回答

JSON本身并没有指定日期应该如何表示，但 JavaScript 可以。

您应该使用Date'stoJSON方法发出的格式：

2012-04-23T18:25:43.511Z

原因如下：

  1. 它是人类可读的，但也很简洁

  2. 它排序正确

  3. 它包括小数秒，可以帮助重新建立年表

  4. 它符合ISO 8601

  5. ISO 8601 已在国际上确立了十多年

  6. ISO 8601 得到W3C、RFC3339和XKCD 的认可

话虽如此，曾经编写过的每个日期库都可以理解“自 1970 年以来的毫秒数”。所以为了便于携带，ThiefMaster是正确的。

我会在列表中添加另一个重要原因：它与语言环境无关。如果您有一个类似 02-03-2014 的日期，您需要其他信息才能知道它是指 2 月 3 日还是 3 月 2 日。这取决于使用的是美国格式还是其他格式。
2021-03-14 03:56:45
实际上，@Erfa，由于-出现在 中的数字之前ASCII，所以它会一直排序到 100,000 年。;P
2021-03-15 03:56:45
为提及和链接 xkcd 点赞 :D @ajorquera 我通常为此使用 momentjs。我也看到了 IE 在这方面的问题
2021-04-04 03:56:45
这也是ECMA的首选表示：JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}"
2021-04-07 03:56:45
关于第二点，它在 10000 年之后排序不正确。不过，我们确实有将近 8000 年的时间来提出新格式，所以这可能不是问题。
2021-04-09 03:56:45

JSON 对日期一无所知。.NET 所做的是一个非标准的 hack/扩展。

我会使用一种可以轻松转换为DateJavaScript 对象的格式，即可以传递给new Date(...). 最简单也可能是最便携的格式是包含自 1970 年以来毫秒的时间戳。

正如@BenDolman 所说，这个“解决方案”不能恰当地处理 1970 年 1 月 1 日（纪元）之前的日期。此外，首先存在 ISO8601 是有原因的。在地球上，我们有一些叫做“时区”的东西。以毫秒为单位在哪里？JSON可能没有日期的标准，但日期外存在JSON的，有是一个标准这一点。funroll 的答案是正确的（另请参阅：xkcd.com/1179）。
2021-03-19 03:56:45
也许还值得一提的是，从 1970 年开始的 (milli) 秒对于未来的日期是不可预测的，因为我们有闰秒。所以我不会将 if 用于进程间通信和数据存储。然而，在程序内部使用它是很好的，因为它可以存储在一个整数中，这会给你一些性能优势。
2021-03-25 03:56:45
Unix 时间戳始终是 UTC，您在生成时间戳之前从本地时区转换，然后再次返回到显示的本地时区，那里没有歧义。
2021-03-28 03:56:45
如果您走这条路线，请确保您不需要处理早于 1970 年的日期！
2021-03-29 03:56:45
这些评论中的每一条都不能代表 1970 年代之前的日期或未来的日期，这都是对纪元时间的误解。所有时间都是相对的，一旦您到达/低于第 1 年，日期字符串就会真正分解。无论您的时间的源时钟是什么，几乎可以肯定它无论如何都基于纪元时间的表示，所以您没有做到通过避免纪元时间更准确。
2021-03-31 03:56:45

没有正确的格式；的JSON规范不以交换日期这就是为什么有这么多不同的方式来做到这一点指定的格式。

最好的格式可以说是以ISO 8601 格式表示的日期（请参阅维基百科）；它是一种众所周知且广泛使用的格式，可以跨多种不同的语言进行处理，因此非常适合互操作性。如果您可以控制生成的json，例如您以json格式向其他系统提供数据，那么选择8601作为日期交换格式是一个不错的选择。

如果您无法控制生成的 json，例如，您是来自多个不同现有系统的 json 的使用者，则处理此问题的最佳方法是使用日期解析实用程序函数来处理预期的不同格式。

JSON 模式规范实际上说模式验证的日期必须是 8601 格式。
2021-03-12 03:56:45
@vallismortis - 这是用于定义各方之间交换的给定 json 结构的架构的规范草案，而不是 json 规范中的日期格式。我将根据评论修改我的答案，看来我说得不够清楚
2021-03-13 03:56:45
@mlissner 但这是关于哪个最好的意见。ISO-8601 是一个标准，但它不是JSON 的标准（即使我倾向于使用它）；例如，Microsoft 决定不使用它 ( msdn.microsoft.com/en-us/library/... )。最好的做法是坚持一个（合理的）约定，无论是什么。正如我在回答中所述，处理此问题的最佳方法是定义一个可以处理预期格式的日期解析实用程序函数。如果您与使用不同格式的系统集成，则该函数应处理每种情况。
2021-03-22 03:56:45
@RussCam，我们可以来回切换，但如果有人问以 JSON 编码日期的最佳方法，他们会问在制作 JSON 时如何格式化日期（答案通常是 ISO-8601）。您正在回答相反的问题：如何在已经制作的 JSON 日期之后使用它们（尽管您的建议是合理的）。
2021-03-22 03:56:45
@gnasher729 你有链接吗？
2021-04-03 03:56:45

来自RFC 7493（I-JSON 消息格式）：

I-JSON 代表 Internet JSON 或 Interoperable JSON，具体取决于您询问的对象。

协议通常包含旨在包含时间戳或持续时间的数据项。建议将所有此类数据项表示为 ISO 8601 格式的字符串值，如RFC 3339 中所述，附加限制是使用大写而不是小写字母，不默认包含时区，以及可选的尾随秒即使它们的值为“00”，也包括在内。还建议所有包含持续时间的数据项符合 RFC 3339 附录 A 中的“持续时间”产生式，具有相同的附加限制。

这也是Date().toISOString()and生成的格式Date().toJSON()，其限制是Date不跟踪时区值，因此总是在 UTC ( Z) 时区发出时间戳。可以使用new Date("...")和解析该值Date.parseDate。
2021-03-18 03:56:45

如有疑问，只需按F12（Firefox 中的Ctrl+ Shift+ K）转到现代浏览器的 javascript Web 控制台并编写以下内容：

new Date().toISOString()

将输出：

“2019-07-04T13:33:03.969Z”

达达！！

其它你可能感兴趣的问题
上一篇如何显示 JavaScript 对象？ 下一篇如何向给定元素添加类？