我见过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

哪一个是正确的?还是最好的?这方面有什么标准吗?


当前回答

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

new Date().toISOString()

将输出:

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

大大!!

其他回答

JSON本身没有日期格式,它不在乎任何人如何存储日期。然而,由于这个问题用javascript标记,我假设您想知道如何在JSON中存储javascript日期。您只需将日期传递给JSON.stringify方法,默认情况下,它将使用date.prototype.toJSON,而date.prototype.toISOString(MDN on date.toJSON):

const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object

我还发现每当我读取JSON字符串时,使用JSON.parse(JSON.pase上的MDN)的reviver参数将ISO字符串自动转换回javascript日期非常有用。

const isoDatePattern = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);

const obj = {
 a: 'foo',
 b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);

// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
    if (typeof value === 'string' &&  value.match(isoDatePattern)){
        return new Date(value); // isostring, so cast to js date
    }
    return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...

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

yourDate.substring(0,10)

这可能对你有帮助

仅供参考,我见过这种格式:

Date.UTC(2017,2,22)

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

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

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

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

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

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

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

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

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

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