3

在进行一些测试时，我发现使用以下 javascript 的浏览器之间的行为不一致

new Date("2013-09-10T08:00:00").toString()

在 IE 和 Firefox 中，结果是

“2013 年 9 月 10 日星期二 08:00:00 GMT-0400（东部夏令时间）”

在 Chrome 中，结果是

“2013 年 9 月 10 日星期二 04:00:00 GMT-0400（东部夏令时间）”

因此，根据我对日期字符串格式的ECMA脚本的阅读，它说...

所有数字必须以 10 为底。如果 MM 或 DD 字段不存在，则使用“01”作为值。如果 HH、mm 或 ss 字段不存在，则使用“00”作为值，并且不存在的 sss 字段的值为“000”。 缺席时区偏移的值为“Z”

但是在“new Date()”构造函数的文档中它说

15.9.3.2 新日期（值）

  1. 令 v 为 ToPrimitive(value)。

  2. 如果 Type(v) 是字符串，那么

    一种。将 v 解析为日期，其方式与解析方法 (15.9.4.2) 完全相同；设 V 为该日期的时间值。

15.9.4.2 日期解析（字符串）

parse 函数将 ToString 运算符应用于其参数，并将生成的 String 解释为日期和时间；它返回一个数字，对应于日期和时间的 UTC 时间值。取决于字符串的内容，字符串可能被解释为本地时间、UTC 时间或某个其他时区的时间。

任何想法哪个实施是正确的？

4

2 回答 2

5

标准冲突。ISO 8601规定：

如果没有给出带有时间表示的 UTC 关系信息，则假定时间为本地时间。

ECMA说：

缺席时区偏移的值为“Z”。

Mozilla 开发人员认为ISO 优先，Chrome 的人似乎不同意。

当前的 ES6 草案说（在 20.3.1.15 下）：

如果不存在时区偏移量，则日期时间将被解释为本地时间。

所以Mozilla的实现是（将是）正确的。

于 2013-10-09T17:40:51.730 回答
1

stackoverflow.com 上有几个问题可以解决这个问题。如果有人阅读本文对浏览器到浏览器的详细信息感兴趣，我在这里给出了相当详尽的解释。

不过，最重要的是，至少现在，您应该避免使用 ISO 8601 格式，或者在使用时始终包含时区说明符。而且，永远不要使用 'YYYY-MM-dd' 格式，因为它会被解释为没有时区说明符的 ISO 8601 的简短版本。

于 2013-12-14T18:28:29.117 回答