python - asyncio.loop.time() 是否与 datetime.datetime.now() 具有可比性？如何？

Question

我希望使用 asyncio.loop 在特定时间设置回调。我的问题是我需要根据 datetime.datetime 对象 (UTC) 安排这些，但 asyncio.loop.call_at() 使用内部引用时间。

在 Ubuntu 上运行的 python 3.7.3 的快速测试显示 asyncio.loop.time() 正在报告系统正常运行时间。对于转换，我的第一个想法是天真地存储一个引用时间并在以后使用它:

from asyncio import new_event_loop
from datetime import datetime, timedelta

_loop = new_event_loop()
_loop_base_time = datetime.utcnow() - timedelta(seconds=_loop.time())

def schedule_at(when, callback, *args):
    _loop.call_at((when - _loop_base_time).total_seconds(), callback, *args)

然而，尚不清楚此偏移量 (datetime.utcnow() - timedelta(seconds=loop.time())) 是否稳定。我不知道系统正常运行时间与 UTC 相比是否有漂移，即使系统时钟已修改(例如:通过 NTP 更新)。

请记住，这是针对可能一次运行数月的监控软件，小的漂移可能非常重要。我应该注意到，我已经看到系统每天在没有 NTP 守护程序的情况下损失几分钟，并且一次关闭的 NTP 更新可以在短时间内将时间改变许多分钟。由于我不知道两者是否保持同步，因此不清楚我需要关注多少。

---

注意:我知道 python 将事件安排在未来超过 24 小时的问题。我将通过将遥远的 future 事件存储在列表中并每 12 小时轮询一次即将发生的事件来解决这个问题，仅在未来 < 24 小时内安排它们。

---

是否可以可靠地将 datetime.datetime 时间转换为 asyncio.loop 时间？或者这两个时间系统是无可比拟的？如果它们具有可比性，我是否需要做任何特别的事情来确保我的计算是正确的。

Answer 1

您可以使用与用于调度的时间框架相同的时间框架来计算秒数差异，然后将 asyncio.call_later 与计算出的延迟一起使用:

def schedule_at(when, callback, *args):
  delay = (when - datetime.utcnow()).total_seconds()
  _loop.call_later(delay, callback, *args)

这将解决循环时间与 utcnow 之间的差异是否稳定的问题；它只需要在安排任务的时间和执行任务的时间之间保持稳定(根据您的笔记，应该少于 12 小时)。

例如:如果事件循环的内部时钟每小时从 utcnow 漂移 1 秒(故意极端的例子)，则每个任务最多漂移 12 秒，但您不会累积这个运行数月的错误。与使用固定引用的方法相比，这种方法提供了更好的保证。