新加入的日期（ “”）GMT小时

var start = new Date("2017-04-09T21:00:00");

输出：星期一2017年4月10日05:00:00 GMT + 0800（+08）新加入的日期（ “”）GMT小时

它假设是：太阳2017年4月9日21:00： 00 GMT + 0800（+08）

来源

2017-04-09 User1911

远程'T'从' “2017-04-09T21：00：00”' – gurvinder372

但是我使用FullCalendar比它做工精细，而把日期用'T'。 – User1911

start.toUTCString（）; ？ – ThatAwesomeCoder

这很容易。你可以试试这个：

var start = new Date("2017-04-09T21:00:00"); 
 
start.setTime(start.getTime() + start.getTimezoneOffset()*60*1000); 
 

 
console.log(start);

来源

2017-04-09 14:14:30

除了'新日期（“2017-04-09T21：00：00”）'在不同的浏览器中返回不同的结果。对于我而言，在Firefox 49中，上述内容返回“2017-04-09T01：00：00.000Z”。在Safari中，它返回“2017-04-09T11：00：00.000Z”。根据ECMA-262，它应被视为本地的，因此不需要对当地时区进行调整。 – RobG

在firefox中，当您将参数传递给Date（）构造函数时，将其视为本地时间并返回格林威治标准时间。但是，在Chrome中，参数被视为格林威治标准时间并返回当地时间。因此，您需要检测浏览器并根据此计算时间（输出）。但我不明白为什么Safari会返回意想不到的结果。 –

如果你走向浏览器嗅探的道路，你就处于一个痛苦的世界。只需手动解析字符串。 – RobG

有一个黄金法则，你不应该解析与Date构造函数的字符串（或Date.parse，它们是等价的解析）。

据ECMA-262，没有一个时区的ISO 8601格式的日期应被视为本地：

当时间区偏移量不存在，日期只有形式解释为UTC时间和日期 - 时间表被解释为当地时间。

因此new Date("2017-04-09T21:00:00")应在宿主时区返回2017年4月9日晚上9:00的日期。

但是，Safari 10和Chrome 57中的测试显示“2017-04-09T21：00：00”被视为Z或GMT + 0000。 Firefox 49奇怪地将它视为UTC，然后以错误的方式调整当地时区。但是，Firefox 38正确地将其视为本地。

所以总是手动解析字符串。使用库或写一个简短的功能，例如

// Parse 2017-04-09T11:00:00.000 as local 
 
function parseISOLocal(s) { 
 
    var b = s.split(/\D/); 
 
    return new Date(b[0], b[1]-1, b[2], (b[3]||0), 
 
       (b[4]||0), (b[5]||0), (b[6]||0)); 
 
} 
 

 
var s = '2017-04-09T21:00:00.000'; 
 
console.log('Built-in parser: ' + new Date(s).toString()); 
 
console.log('parseISOLocal : ' + parseISOLocal(s).toString());

来源

2017-04-09 21:06:55 RobG

新加入的日期（ “”）GMT小时

回答

相关问题