首选的方法是使用2018-04-23T18:25:43.511Z。。。

下图显示了为什么这是首选方式：

因此，正如您所看到的，Date有一个原生的方法toJSON，它以这种格式返回，并且可以很容易地再次转换为Date。。。

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

我会使用一种可以很容易地转换为JavaScript中的Date对象的格式，即可以传递给新的Date（…）的格式。最简单也是最可移植的格式是1970年以来包含毫秒的时间戳。

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

Date.UTC(2017,2,22)

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

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

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

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

“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

以下代码对我有效。此代码将以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);

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

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

2012-04-23T18:25:43.511Z

原因如下：

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

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