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

它对我来说解析服务器工作

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

对此只有一个正确的答案，大多数系统都会弄错。自纪元以来的毫秒数，又称64位整数。时区是一个与UI有关的问题，在应用程序层或数据库层中没有事务。为什么您的数据库为什么要关心什么时区，当您知道它将以64位整数形式存储时，然后进行转换计算。

去除多余的位，仅将日期视为直到UI的数字。您可以使用简单的算术运算符进行查询和逻辑。

“ 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），除非您特别需要弄清楚生成日期的时区（仅在服务器端生成中才可以）。

注意：var date = new Date（）; console.log（date）; // 2014年1月1日星期三13:28:56 GMT- 1000（夏威夷标准时间）

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

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

yourDate.substring(0,10)

这可能对您有帮助

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

{ "myDateField": { "$date" : <ms-since-epoch> } }

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

好处

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

结论

我了解人类可读的格式（ISO-8601字符串）在80％的用例中都是有用的，并且更加方便，并且确实没有人被告知不要将它们的日期存储为ISO-8601字符串，如果这就是他们的应用理解，但是对于一种普遍接受的传输格式，该格式应保证某些值可以肯定是日期，我们如何允许歧义和需要进行大量验证？

首选方式是使用2018-04-23T18:25:43.511Z...

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

因此，如您所见，Date具有本机方法toJSON，该方法return采用这种格式，可以轻松地Date再次转换为...

如有疑问，只需按F12键（在Firefox中为Ctrl + K），转到现代浏览器的javascript Web控制台，然后编写以下代码：

new Date().toISOString()

将输出：

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

-！

仅供参考，我已经看到使用此格式：

Date.UTC(2017,2,22)

它与该功能支持的JSONP一起使用$.getJSON()。不确定我是否会推荐这种方法...只是把它扔掉是有可能的，因为人们是这样做的。

FWIW：切勿在通信协议中使用自纪元以来的秒数，也不要自纪元以来的毫秒数，因为由于leap秒的随机实现而使它们充满了危险（您不知道发送方和接收方是否都正确实现了UTC leap秒）。

有点讨厌，但许多人认为UTC只是GMT的新名称-错误！如果您的系统未实现leap秒，则说明您使用的是GMT（尽管不正确，但通常称为UTC）。如果您完全实现了leap秒，则说明您确实在使用UTC。无法知道未来的leap秒；它们会在必要时由IERS发布，并且需要不断更新。如果您正在运行一个试图实施leap秒但包含和过时的参考表（比您想象的更常见）的系统，那么您既没有GMT也没有UTC，那么您就拥有一个伪装为UTC的系统。

这些日期计数器仅在以细分格式（y，m，d等）表示时才兼容。它们从未以时代格式兼容。记住这一点。

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

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

If you do not have control over the generated json, for example, you are the consumer of json from several different existing systems, the best way of handling this is to have a date parsing utility function to handle the different formats expected.

从RFC 7493（I-JSON消息格式）开始：

I-JSON代表Internet JSON或可互操作JSON，具体取决于您问谁。

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

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

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