当前位置: 首页 > 面试题库 >

JavaScript时区对于过去的夏令时过渡规则是错误的

芮意
2023-03-14
问题内容

在2007年,我们改用夏令时的日子发生了变化。在此更改之前,属于DST扩展范围的任何日期都将报告Chrome和Firefox中的时区偏移不正确。就像Firefox和Chrome不用注意DST过去的日子不同。

如果运行以下脚本,它将报告偏移量为240分钟。这是不正确的,它应该报告300分钟。IE10可以正确执行此操作。有人知道解决办法吗?

alert(new Date('11/04/2004').getTimezoneOffset());

更新:

这是我刚刚一起学习的一段有趣的代码(请参见下文)。令人惊讶的是,除了IE之外,每种日期在大多数浏览器中的距离还有多远。

我最终只是用我自己的Date原型来替换getTimezoneOffset的Date原型,该原型基于硬编码表进行计算。这对我们有用,因为我们仅在美国开展业务,但这是我能想到的最糟糕的解决方案…

<!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规则,而忽略在检查的特定日期/时间到位的规则。参见ES515.9.1.8:


ECMAScript的实现不应尝试确定确切的时间是否受夏时制的限制,而应确定如果当时使用了当前的夏时制算法,则夏时制是否会生效。这避免了诸如此类的复杂性考虑到该语言环境全年观察夏令时的情况。”

规则是:将当前DST规则应用于指定的任何时间。这会导致胡言乱语,但这是ECMAScript要求的。

在将来的ECMAScript版本中,这种行为可能甚至会改变,要求在所有时间点都使用实际的DST规则。最初并不需要这样做,因为它会给实现者带来发送tzdata的负担。语言已经变得足够重要,但是从长远来看,也许每个人都必须掌握它。但是就我所知,这种变化可能还需要数年,所以不要屏住呼吸。



 类似资料:
  • 问题内容: 在2007年,我们改用夏令时的日子发生了变化。在此更改之前,属于DST扩展范围的任何日期都将报告Chrome和Firefox中的时区偏移不正确。就像Firefox和Chrome不用注意DST过去的日子不同。 如果运行以下脚本,它将报告偏移量为240分钟。这是不正确的,它应该报告300分钟。IE10可以正确执行此操作。有人知道解决办法吗? 更新: 这是我刚刚一起学习的一段有趣的代码(请参

  • 本文向大家介绍过渡到微服务时的常见错误相关面试题,主要包含被问及过渡到微服务时的常见错误时的应答技巧和注意事项,需要的朋友参考一下 不仅在开发上,而且在方面流程也经常发生错误。一些常见错误是: 通常开发人员无法概述当前的挑战。 重写已经存在的程序。 职责、时间线和界限没有明确定义。 未能从一开始就实施和确定自动化的范围。

  • 有没有一个时区,我可以使用,以考虑到夏令时?我知道'EDT'是指夏令时,而'EST'不是。是否有一个时区我可以使用,将自动检测日期时间是否是夏令时?“ET”或“America/New_York”能行吗? 编辑:: 抱歉应该更清楚。我想取一个日期并将其转换为东部时区,但我希望它考虑到东部时区的日期是否为夏令时。

  • 轻触方格启用设定,即可将夏令时反映于时间显示中。

  • 问题内容: 我正在编写一个处理很多时区并跨越时区的程序。我最常处理的两件事是从“ now”创建一个datetime对象,然后本地化一个朴素的datetime对象。 要从现在开始在太平洋时区创建datetime对象,我目前正在执行此操作(python 2.7.2+) 关于DST,这是否正确?如果没有,我想应该这样做: 我的问题是为什么?谁能告诉我第一个错误而第二个秒正确的情况? 至于我的秒数问题,假

  • 问题内容: 土耳其最近(2016年9月6日)决定永久停留在夏令时(DST)。该法案取消了原定于2016年10月30日04:00:00的DST结束。时钟没有改变。 土耳其介于之间,因此现在将保持在+3。在这里你可以看到 https://www.timeanddate.com/time/change/turkey/ankara?year=2016 …以及Wikipedia页面 中的“土耳其时间” 和这