【发布时间】:2017-09-28 16:49:32
【问题描述】:
在我们的代码中,我们之前是这样计算事件之间的差异的:
var beginTime = new Date();
// Do stuff
var endTime = new Date();
var duration = endTime.getTime() - beginTime.getTime();
console.log("Job began at " + beginTime.toUTCString()
+ " and took " + duration + " milliseconds.");
这会产生一个人类可读的字符串:
作业于 2017 年 9 月 28 日星期四 11:17:33 GMT-0500(中部夏令时)开始,耗时 7000 毫秒。
我们决定改用High Resolution Time,使用更可靠的performance.now()。但是,我们仍然希望能够包含人类可读的 UTC 时间字符串。
最初,我们尝试了这个:
var beginTime = performance.now();
// Do stuff
var endTime = performance.now();
var duration = endTime - beginTime;
console.log("Job began at " + new Date(beginTime).toUTCString()
+ " and took " + duration + " seconds.");
我们发现持续时间是准确的,但 new Date(performance.now()) 导致 UTC 值不准确(在撰写本文时,它提供了近 50 年前的日期)。
作业开始于 1969 年 12 月 31 日星期三 20:10:46 GMT-0600(中部标准时间),耗时 7000 毫秒。
有没有更好的方法将performance.now() 的输出转换为准确的UTC 字符串?它不必与new Date().toUTCString() 的格式完全相同,但应该是人类可读的。
【问题讨论】:
-
performance.now() 以毫秒为单位给出导航开始的时间。 (不是自 1970 年以来)
-
他们做不同的事情。 stackoverflow.com/questions/30795525/…
-
你在做什么需要 5 微秒的精度。还是您刚刚阅读了一篇点击诱饵文章。
-
@Darkrum 我们实际上需要生存的系统时钟操作,而不是微秒精度。我们的实际工作比示例花费的时间更长,并且我们遇到了一些情况,即在工作期间运行 Windows 时间更新并产生不良结果。
-
@Thunderforge 我明白了。但这是没有正确配置服务器的错误,IMO 不值得付出努力。只需在测试期间以编程方式禁用 Windows 时间更新。
标签: javascript datetime high-resolution-time