没有正确的格式；JSON规范没有指定交换日期的格式，这就是为什么有这么多不同的方法。

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

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

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

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

2012-04-23T18:25:43.511Z

原因如下：

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

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

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

{
"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所指出的）。同样，这仅适用于具有相同时区偏移的日期时间。

我认为通用互操作性的最佳格式不是ISO-8601字符串，而是EJSON使用的格式：

｛“myDateField”：｛“$date”：＜ms since epoch＞｝｝

如下所述：https://docs.meteor.com/api/ejson.html

福利

解析性能：如果您将日期存储为ISO-8601字符串，那么如果您希望在该特定字段下有一个日期值，那么这是很好的，但是如果您有一个系统必须在没有上下文的情况下确定值类型，那么您将解析每个字符串的日期格式。无需日期验证：您不必担心日期的验证和验证。即使字符串与ISO-8601格式匹配，它也可能不是真正的日期；这绝不会发生在EJSON约会中。明确的类型声明：就通用数据系统而言，如果您希望在一种情况下将ISO字符串存储为字符串，而在另一种情况中存储真实的系统日期，则采用ISO-8601字符串格式的通用系统在机械上不允许这样做（没有转义技巧或类似的糟糕解决方案）。

结论

我知道，人类可读的格式（ISO-8601字符串）对于80%的用例来说是有用的，而且更方便，如果应用程序能够理解的话，确实不应该告诉任何人不要将日期存储为ISO-8601的字符串，但是对于一种普遍接受的传输格式来说，我们怎么能允许歧义和这么多验证的需要？

这是我的工作与解析服务器

{
    "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"
            }
}

“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），除非您特别需要确定生成日期的时区（只有在服务器端生成时才可能）。

NB:

    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