【问题标题】:Accuracy of Date.now() in browsers浏览器中 Date.now() 的准确性
【发布时间】:2019-11-28 21:41:15
【问题描述】:

我已经看到很多关于如何在 JavaScript 中获取日期/时间的问题,答案总是类似于

Date.now() 以毫秒为单位返回 UTC 时间戳

但这个值真的可靠吗?它只是基于运行浏览器的任何计算机的系统时钟吗?如果是这样,它似乎与真正的 UTC 时间相差很远,但应该有多少变化?我知道关心精确的毫秒是一个失败的原因,但是以秒或分钟为单位呢?

【问题讨论】:

  • 除非您呼叫外部时钟,否则所有赌注都将被取消。即使那样,它也是粗略的。

标签: javascript date timestamp utc


【解决方案1】:

它只是基于运行浏览器的任何计算机的系统时钟吗?

没错。这很可能是完全不准确的。例如,在我的计算机上,它的时钟不准确,此时,Date.now() 返回1563724931361,当传递给new Date 时,给出:

2019 年 7 月 21 日星期日 11:02:11 GMT-0500(中部夏令时间)

这是完全错误的。

如果客户希望提供不准确的Date.now(),他们这样做是很简单的,虽然通常,对于大多数普通用户来说,它会是准确的,因为大多数 人们有准确的时钟。

准确度如何?这取决于硬件,自他们的计算机上次从时间服务器请求时间以来的时间,以及计算机开机(从电源关闭或待机/休眠)以来的时间,但大多数情况下,它赢了不要超过一分钟。

【讨论】:

    【解决方案2】:

    总有ECMA-262

    20.3.3.1 Date.now ( )

    now 函数返回一个数字值,即time value 指定调用 now 的 UTC 日期和时间。

    就是这样,对值的来源或其准确性没有要求,因此它取决于实现。在实践中,似乎大多数实现都使用来自主机系统的值,因此可靠性并不比系统时钟和用户提供的设置(例如日历、时区、DST、当前时间等)的预期更好。

    【讨论】:

      【解决方案3】:

      鉴于side-channel memory attacks,浏览器中计时源的准确性受到限制。根据目前的信息,来自W3C High Resolution Time issue tracker,不同浏览器的限制略有不同:

      • 移动 Chrome + Edge:100us + 100us 抖动
      • 桌面 Chrome:5us
      • Safari + Firefox:1 毫秒

      【讨论】:

        猜你喜欢
        • 2017-05-23
        • 2016-07-04
        • 1970-01-01
        • 1970-01-01
        • 2013-03-13
        • 1970-01-01
        • 2013-01-12
        • 2018-08-16
        • 1970-01-01
        相关资源
        最近更新 更多