新的date（）在Chrome和Firefox中的工作方式不同
我想通过JavaScript将datestring转换为Date ，使用下面的代码：
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)
这是不同的一天，我期望正确的结果是从Chrome的结果。
演示代码： http : //jsfiddle.net/xHtqa/2/
我怎样才能解决这个问题，以获得相同的结果？
UTC的正确格式为2013-02-27T17:00:00Z （Z表示Zulu时间）。 如果不存在，则附加Z以获取正确的UTCdate时间string。
是的，不幸的是date分析algorithm是依赖于实现的。 从Date.parse的规范 （由new Date ）：
根据string的内容，string可能被解释为本地时间，UTC时间或某个其他时区的时间。 函数首先尝试根据date时间string格式（ 15.9.1.15 ）中调出的规则来parsingstring的格式。 如果string不符合该格式，该函数可能会回退到任何特定于实现的启发式或实现特定的date格式。
要使Date构造函数不（可能）使用本地时区，请使用带有时区信息的date时间string，例如"2013-02-27T17:00:00Z" 。 但是，很难find每个浏览器可靠parsing的格式–ISO格式不被IE <8识别（请参阅JavaScript：哪些浏览器支持使用Date.parseparsingISO-8601datestring ）。 更好的办法是使用unix时间戳，例如unix时代以来的毫秒数，或者使用regulareexpression式将string向下拆分，然后将其input到Date.UTC 。
我在这里find了一件事。 看起来原生的Firefox Inspector控制台可能有一个错误：如果我在本地Inspector中运行“new Date（）”，它会显示错误的时区，GMT区域设置的date，但在Firebug扩展控制台中运行相同的命令，date显示使用我的正确时区（GMT-3：00）。
尝试使用moment.js。 它和所有的浏览器都很相似。 附带许多格式选项。 使用时间（'date'）。格式（“”）而不是新date（'date'）
注意到FireFox没有返回与Chrome相同的结果。 看起来像你在kendo.toString中使用的date格式有所不同。
最后的控制台结果是我所需要的：
