在Chrome和Firefox中，New Date()的工作方式不同

Question

在Chrome和Firefox中，New Date()的工作方式不同

我想将日期字符串转换为Date通过javascript，使用以下代码：

var date = new Date('2013-02-27T17:00:00');alert(date);

'2013-02-27T17:00:00'是来自服务器的JSON对象中的UTC时间。

但上述代码的结果在Firefox和Chrome之间是不同的：

Firefox返回：

Wed Feb 27 2013 17:00:00 GMT+0700 (SE Asia Standard Time)

Chrome返回：

Thu Feb 28 2013 00:00:00 GMT+0700 (SE Asia Standard Time)

这是不同的1天，正确的结果，我希望是从Chrome的结果。

演示代码：http://jsfiddle.net/xHtqa/2/

我怎样才能解决这个问题，从这两个问题中得到相同的结果？

Answer 1

是的，不幸的是，日期解析算法依赖于实现。从规范Date.parse(由new Date):根据字符串的内容，可以将字符串解释为本地时间、UTC时间或其他时区中的时间。函数首先尝试根据日期时间字符串格式中调用的规则解析字符串的格式(15.9.1.15)。如果字符串不符合该格式，则函数可能返回到任何特定于实现的启发式或特定于实现的日期格式。使Date构造器不是(也许)使用本地时区，而是使用带有时区信息的日期时间字符串。"2013-02-27T17:00:00Z"..然而，很难找到每一个浏览器都能分析的可靠格式-IE<8不承认ISO格式(请参见JavaScript：哪些浏览器支持使用Date.parse解析ISO-8601日期字符串)。更好的方法是使用Unix时间戳，即Unix时代，或者使用正则表达式分解字符串的各个部分，然后将其输入Date.UTC.

Answer 2

我在这里发现了一件事。本地Firefox检查器控制台似乎有一个错误：如果我在本机检查器中运行“newdate()”，它会显示一个带有错误时区的日期，GMT地区，但是在Firebug扩展控制台中运行相同的命令，显示的日期使用我的正确时区(GMT-3：00)。

Answer 3

UTC的正确格式是2013-02-27T17:00:00Z(Z代表祖鲁时间)附加Z如果不存在，则获取正确的UTC日期时间字符串。