我见过JSON日期格式的许多不同标准:

"\"\\/Date(1335205592410)\\/\""         .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\""    .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z"              JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00"             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"
            }
}

其他回答

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

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

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

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

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

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

没有正确的格式;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是正确的。