在进行一些测试时，我发现浏览器与以下javascript之间的行为不一致
new Date("2013-09-10T08:00:00").toString()
在IE和Firefox中，结果是
＆＃34; Tue Sep 10 2013 08:00:00 GMT-0400（东部夏令时）＆＃34;
在Chrome中，结果为
＆＃34; Tue Sep 10 2013 04:00:00 GMT-0400（东部夏令时）＆＃34;
所以根据我阅读日期字符串格式的ECMA脚本，它说......
所有数字必须为10。如果缺少MM或DD字段＆＃34; 01＆＃34;是 用作值。如果缺少HH，mm或ss字段＆＃34; 00＆＃34;是 用作缺席sss字段的值和值是＆＃34; 000＆＃34;。 缺席时区偏移的值为＆＃34; Z＆＃34;
然而，在＆＃34;新日期（）＆＃34;的文档中;构造函数，它说
15.9.3.2新日期（价值）
- 设v为ToPrimitive（value）。
如果Type（v）是String，那么
一个。将v解析为日期，其方式与解析方法完全相同（15.9.4.2）;让V成为时间 这个日期的价值。
15.9.4.2 Date.parse（string）
parse函数将ToString运算符应用于其参数，并将结果String解释为日期 和时间;它返回一个Number，对应的UTC时间值 日期和时间。 String 可以解释为本地时间，UTC 时间，或在某个其他时区的时间，取决于的内容 字符串。
任何实施的想法都是正确的吗？
答案 0 :(得分：5)
标准冲突。 ISO 8601 states that：
如果没有给出时间表示的UTC关系信息，则假定时间是当地时间。
ECMA says：
缺席时区偏移的值为“Z”。
Mozilla开发者think认为ISO优先，Chrome人似乎不同意。
current draft of ES6说（根据20.3.1.15）：
如果没有时区偏移，则将日期时间解释为当地时间。
所以Mozilla的实现是（将）是正确的。
答案 1 :(得分：1)
stackoverflow.com上有几个问题可以解决这个问题。如果阅读此内容的任何人对浏览器到浏览器的详细信息感兴趣，我会给出一个相当彻底的解释here。
但最重要的是，至少现在，您应该一起避免使用ISO 8601格式，或者在使用时始终包含时区说明符。并且，永远不要使用'YYYY-MM-dd'格式，因为它被解释为没有时区说明符的ISO 8601的简短版本。