我认为通用互操作性的最佳格式不是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的字符串，但是对于一种普遍接受的传输格式来说，我们怎么能允许歧义和这么多验证的需要？

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

yourDate.substring(0,10)

这可能对你有帮助

如果有疑问，只需按F12（在Firefox中为Ctrl+Shift+K）进入现代浏览器的javascript web控制台，并编写以下内容：

new Date().toISOString()

将输出：

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

大大！！

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

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

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

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

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

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

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

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

2012-04-23T18:25:43.511Z

原因如下：

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

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