如何用 JSON 表示日期和/或时间信息？
JSON 文本 (RFC 4627) 具有对象、数组、字符串的明确表示、数字、布尔值（字面意思是 true 或 false）和 null。 但是，它没有定义任何用于表示时间信息（例如日期和时间）的定义，这在应用程序中很常见。 考虑到 RFC 4627？
受访者注意事项：该问题的目的是记录已知正在使用的各种方法以及示例和相对优缺点（最好来自现场经验）。
JSON text (RFC 4627) has unambigious representation of objects, arrays, strings, numbers, Boolean values (literally true or false) and null. However, it has nothing defined for representing time information like date and time of day, which is very common in applications. What are the current methods in use to represent time in JSON given the constraints and grammar laid out in RFC 4627?
Note to respondents: The purpose of this question is to document the various methods known to be in circulation along with examples and relative pros and cons (ideally from field experience).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
很抱歉对这样一个老问题发表评论，但在接下来的几年里，出现了更多的解决方案。
在 JSON 中表示日期和/或时间信息是在 JSON 中表示复杂类型和复杂数据结构的更普遍问题的一个特例。 使问题变得棘手的部分原因是，如果您将时间戳等复杂类型表示为 JSON 对象，那么您需要一种表达关联数组和对象的方式，这恰好看起来像时间戳的 JSON 对象表示，就像其他一些对象一样标记的对象。
Google 的协议缓冲区有一个JSON 映射 它具有时间戳类型的概念，具有定义的语义。
MongoDB 的 BSON 有一个 扩展 JSON 表示
{ "$date": "2017-05-17T23:09:14.000000Z" }。除了日期时间之外，两者还可以表达更复杂的结构。
Sorry to comment on such an old question, but in the intervening years more solutions have turned up.
Representing date and/or time information in JSON is a special case of the more general problem of representing complex types and complex data structures in JSON. Part of what make the problem tricky is that if you represent complex types like timestamps as JSON objects, then you need to have a way of expression associative arrays and objects, which happen to look like your JSON object representation of a timestamp, as some other marked-up object.
Google's protocol buffers have a JSON mapping which has the notion of a timestamp type, with defined semantics.
MongoDB's BSON has an Extended JSON which says
{ "$date": "2017-05-17T23:09:14.000000Z" }.Both can also express way more complex structures in addition to datetime.
我在使用中看到的唯一表示形式（尽管，不可否认，我的经验仅限于 DOJO）是 ISO 8601，效果很好，并且代表了您可能想到的任何内容。
例如，您可以访问上面的链接。
优点：
缺点：
The only representation that I have seen in use (though, admittedly, my experience is limited to DOJO) is ISO 8601, which works nicely, and represents just about anything you could possibly think of.
For examples, you can visit the link above.
Pros:
Cons:
ISO 8601 似乎是一个自然的选择，但如果您想使用在浏览器中运行的 JavaScript 来解析它，则需要使用一个库，因为浏览器支持 JavaScriptDate 对象也是不一致的。 ISO 8601 的另一个问题是它是一个庞大而丰富的标准，并且日期/时间库仅支持其中的一部分，因此您必须选择您使用的库支持的 ISO 8601 子集来使用。
相反，我将时间表示为自 1970-01-01T00:00Z 以来的毫秒数。 在更老的浏览器中，
Date对象的构造函数可以理解这一点，至少可以追溯到 IE7（这是我测试过的最旧的浏览器）。ISO 8601 seems like a natural choice, but if you'd like to parse it with JavaScript running in a browser, you will need to use a library, for browser supports for the parts of the JavaScript
Dateobject that can parse ISO 8601 dates is inconsistent, even in relatively new browsers. Another problem with ISO 8601 is that it is a large, rich standard, and the date/time libraries support only part of it, so you will have to pick a subset of ISO 8601 to use that is supported by the libraries you use.Instead, I represent times as the number of milliseconds since 1970-01-01T00:00Z. This is understood by the constructor for the
Dateobject in much older browsers, at least going back to IE7 (which is the oldest I have tested).没有固定的文字，因此请使用对您来说最简单的文字。 对于大多数人来说，它要么是 UTC 输出的字符串，要么是以 UTC 为中心的时间码的长整数。
阅读此内容以了解更多背景信息： http://msdn.microsoft.com/ en-us/library/bb299886.aspx
There is no set literal so use what's easiest for you. For most people, that's either a string of the UTC output or an long-integer of the UTC-centered timecode.
Read this for a bit more background: http://msdn.microsoft.com/en-us/library/bb299886.aspx
我建议使用 RFC 3339 格式，这种格式很好很简单，并且被越来越多的人理解语言、库和工具。
不幸的是，RFC 3339、Unix 纪元时间和 JavaScript 毫秒时间仍然不太准确，因为它们都没有考虑闰秒！ 在某些时候，我们都将不得不再次重新审视时间表示。 也许下次我们就可以完成它了。
I recommend using RFC 3339 format, which is nice and simple, and understood by an increasing number of languages, libraries, and tools.
Unfortunately, RFC 3339, Unix epoch time, and JavaScript millisecond time, are all still not quite accurate, since none of them account for leap seconds! At some point we're all going to have to revisit time representations yet again. Maybe the next time we can be done with it.