我认为这确实取决于用例。在许多情况下，使用适当的对象模型（而不是将日期呈现为字符串）可能更为有益，如下所示：

{
"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更冗长，但：

它也是人类可读的它实现了一个适当的对象模型（如在OOP中，只要JSON允许）它支持时区（而不仅仅是给定日期和时间的UTC偏移量）它可以支持更小的单位，如毫秒、纳秒。。。或者仅仅是小数秒它不需要单独的解析步骤（解析日期时间字符串），JSON解析器将为您完成一切轻松创建任何日期时间框架或任何语言的实现可以轻松扩展以支持其他日历刻度（希伯来文、中文、伊斯兰…）和时代（公元前、公元前…）10000年是安全的；-）（RFC 3339不是）支持全天日期和浮动时间（Javascript的Date.toJSON（）不支持）

我不认为将日期序列化为JSON时真正需要正确的排序（如RFC 3339的funroll所指出的）。同样，这仅适用于具有相同时区偏移的日期时间。

仅供参考，我见过这种格式：

Date.UTC(2017,2,22)

它与$.getJSON（）函数支持的JSONP一起工作。我不确定我会推荐这种方法。。。只是把它作为一种可能性，因为人们是这样做的。

FWIW：不要在通信协议中使用从epoch开始的秒数，也不要使用从epoth开始的毫秒数，因为由于闰秒的随机实现，这些都充满了危险（你不知道发送方和接收方是否都正确地实现了UTC闰秒）。

有点讨厌，但许多人认为UTC只是GMT的新名称——错了！如果您的系统没有实现闰秒，那么您使用的是GMT（尽管不正确，但通常称为UTC）。如果你完全实现了闰秒，你真的在使用UTC。未来的闰秒是未知的；IERS在必要时发布它们，并需要不断更新。如果您运行的系统试图实现闰秒，但包含过期的参考表（比您想象的更常见），那么您既没有GMT，也没有UTC，那么您的系统就假装是UTC。

这些日期计数器仅在以分解格式（y、m、d等）表示时才兼容。它们在历元格式中从不兼容。记住这一点。

在Sharepoint 2013中，获取JSON格式的数据时，没有将日期转换为仅日期格式的格式，因为在该格式中，日期应为ISO格式

yourDate.substring(0,10)

这可能对你有帮助

对此只有一个正确的答案，大多数系统都搞错了。自epoch以来的毫秒数，也称为64位整数。时区是一个UI问题，在应用层或数据库层没有业务。为什么你的数据库关心什么是时区，当你知道它将存储为64位整数，然后进行转换计算。

去掉多余的部分，将日期视为用户界面上的数字。您可以使用简单的算术运算符来执行查询和逻辑。

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

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

协议通常包含设计用于包含时间戳或持续时间。建议所有此类数据按照规定，项目以ISO 8601格式表示为字符串值在RFC 3339中，附加的限制是大写不包括时区默认值，并且即使在它们的值为“00”。还建议所有数据项包含持续时间符合RFC 3339的附录A，具有相同的附加限制。

JSON本身并没有指定日期的表示方式，但JavaScript确实如此。

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

2012-04-23T18:25:43.511Z

原因如下：

它是人类可读的，但也简洁它排序正确它包括分数秒，这有助于重建年表符合ISO 8601ISO 8601已在国际上建立了十多年ISO 8601由W3C、RFC3339和XKCD认可

也就是说，每一个写过的日期库都可以理解“自1970年以来的毫秒”。因此，为了便于携带，ThiefMaster是正确的。