Я надеюсь использовать asyncio.loop
для установки обратных вызовов в определенное время.Моя проблема в том, что мне нужно планировать их на основе datetime.datetime
объектов (UTC), но asyncio.loop.call_at()
использует внутреннее эталонное время.
Быстрый тест на python 3.7.3, работающем в Ubuntu, показывает, что 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 часов вбудущее.Я смогу обойти это, сохраняя отдаленные будущие события в списке и опрашивая предстоящие события каждые 12 часов, планируя их только тогда, когда они будут <24 часа в будущем. </p>
Возможно линадежно конвертировать из datetime.datetime
в asyncio.loop
раз?или две системы времени несопоставимы?Если они сопоставимы, нужно ли что-то особенное делать, чтобы мои расчеты были правильными.