asyncio.loop.time() 是否与 datetime.datetime.now() 具有可比性以及如何比较？

Question

我希望使用 anasyncio.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())) 是否稳定。我不知道即使系统时钟被修改（例如：通过 NTP 更新），系统正常运行时间与 UTC 相比是否会发生漂移。

请记住，这是针对可能一次运行数月的监控软件，小偏差可能非常重要。我应该指出的是，我见过没有 NTP 守护进程的系统每天会损失几分钟的时间，并且一次性 NTP 更新可能会在短时间内将时间改变很多分钟。由于我不知道两者是否保持同步，因此不清楚我需要关心多少。

---

注意：我知道 python 在安排未来超过 24 小时的事件方面存在问题。我将通过将遥远的未来事件存储在列表中并每 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 小时）。

例如：如果事件循环的内部时钟每小时漂移 1 秒utcnow（故意极端的示例），则每个任务最多会漂移 12 秒，但不会在几个月的运行时间中累积此错误。与使用固定参考的方法相比，这种方法给出了更好的保证。