在2007年,我们改用夏令时的日子发生了变化。在此更改之前,属于DST扩展范围的任何日期都将报告Chrome和Firefox中的时区偏移不正确。就像Firefox和Chrome不用注意DST过去的日子不同。
如果运行以下脚本,它将报告偏移量为240分钟。这是不正确的,它应该报告300分钟。IE10可以正确执行此操作。有人知道解决办法吗?
alert(new Date('11/04/2004').getTimezoneOffset());
更新:
这是我刚刚一起学习的一段有趣的代码(请参见下文)。令人惊讶的是,除了IE之外,每种日期在大多数浏览器中的距离还有多远。比较开始日期和结束日期与此:http : //www.timeanddate.com/worldclock/timezone.html?n=77&syear=2000
我最终只是将自己的Date原型用于getTimezoneOffset,将其替换为我自己的原型,该原型基于硬编码表进行计算。这对我们有用,因为我们仅在美国开展业务,但这是我能想到的最糟糕的解决方案…
<!DOCTYPE html> <html> <head> <title>Moment Test</title> <script src="http://cdnjs.cloudflare.com/ajax/libs/moment.js/2.0.0/moment.min.js"></script> <script src="http://code.jquery.com/jquery-1.10.1.min.js"></script> <script> var lastOffset = null; var $tbody = null; var endDate = new Date('01/01/2021'); function addDate(d) { if($tbody === null) $tbody = $('#dates'); var offset = d.getTimezoneOffset(); var s = ''; if(lastOffset != offset) { if(lastOffset != null) s = '<tr style="background-color: red;">'; lastOffset = offset; } else { s = '<tr>'; } var m = new moment(d); s += '<td>' + m.format('YYYY-MM-DD') + '</td><td>' + m.format('YYYY-MM-DDTHH:mm:ssZ') + '</td><td>' + m.format('YYYY-MM-DDTHH:mm:ss') + '</td><td>' + offset + '</td></tr>'; $tbody.append($(s)); d.setDate(d.getDate() + 1); if(d < endDate) window.setTimeout(function(){addDate(d)}, 0); } </script> </head> <body> <button onclick="addDate(new Date('01/01/1980'));">Fill Table</button> <table border="1"> <thead><tr><th>Date</th><th>Date 2</th><th>Date 3</th><th>TZ Offset</th></tr></thead> <tbody id='dates'></tbody> </table> </body> </html>
实际上是指定行为,以使用当前的DST规则,而忽略在检查的特定日期/时间到位的规则。参见ES5 15.9.1.8:
“ ECMAScript的实现不应尝试确定确切的时间是否受夏时制的约束,而应确定如果当时使用了当前的夏时制算法,则夏时制是否会生效。这避免了诸如此类的复杂性。考虑到该语言环境全年观察夏令时的情况。”
规则是:将当前DST规则应用于指定的任何时间。这会导致胡言乱语,但这正是ECMAScript所要求的。
在将来的ECMAScript版本中,这种行为甚至可能会改变,要求在所有时间点都使用实际的DST规则。最初并不需要这样做,因为它会给实现者带来发送tzdata的负担。语言已经变得足够重要,但是从长远来看,也许每个人都必须掌握它。但是就我所知,这种变化可能还需要数年,所以不要屏住呼吸。