DST-независимое время в Python
У меня есть класс планирования, который принимает объект datetime.time и запускает задачу каждый день в указанное время.
import time
import datetime as dt
class Scheduler:
def set_time(self, day_time):
self._day_time = day_time
self._last_execution = None
def run(self, f):
while True:
time.sleep(10)
now = dt.datetime.now(dt.UTC)
today = now.date()
# Don't run on weekends
if today.weekday() > 4:
continue
# First execution: it can run anytime within the first 5 minutes after the expected time
if self._last_execution is None:
begin = dt.datetime.combine(today, self._day_time)
end = begin + dt.timedelta(minutes=5)
if begin <= now < end:
self._last_execution = now
f()
else:
continue
# Later executions
scheduled = dt.datetime.combine(today, self._day_time)
if self._last_execution < scheduled and now >= scheduled:
self._last_execution = now
f()
scheduler = Scheduler()
scheduler.set_time(dt.time(8, 30, tzinfo=my_timezone))
scheduler.run(lambda: print("This is printed every day at 8:30"))
Предположим, что эта служба работает годами.
Очевидно, проблема в переменной my_timezone. Я хотел бы, чтобы эта задача выполнялась каждый день в одно и то же время, независимо от того, находимся ли мы в летнее время или нет (что, кстати, означает, что если моя задача должна быть запущена в 2:30 утра, она будет запущена дважды при переходе с летнего времени на летнее и пропускается при переходе с летнего на летнее время).
Внутри scheduler сравнивает время, указанное во время настройки, с dt.datetime.now(dt.UTC).
Интересно, как лучше всего справиться с этим. Есть ли tzinfo я могу указать для учета перехода на летнее время?
@slothrop спасибо. Итак, установка my_timezone для географического спецификатора, такого как «Европа/Париж», достаточна для того, что мне нужно? Я не был полностью уверен, потому что создание dt.time(8, 30, tzinfo=my_timezone) выполняется только один раз в начале и боялся, что только тогда будет учитываться часовой пояс. (Я знаю об атрибуте fold)
Можете ли вы добавить к своему вопросу код, который выполняет сравнение времени?
@slothrop: готово (я многое упростил по сравнению с моим реальным кодом, который содержит ненужные детали)
Спасибо. Я думаю, есть пара проблем: (1) в день «возврата» это не вызовет второй запуск (поскольку ваш _day_time будет иметь значение по умолчанию fold=0), (2) today выглядит так, как должно быть. «сегодня» по местному времени, а не по UTC. Например, если мы работаем в часовом поясе Америки/Нью-Йорка и сейчас 2023-07-19 22:00 по местному времени, то today будет 2023-07-20, поэтому begin (или scheduled) будет на 24 часа позже, чем должно. быть.
Но на самом деле: # Don't run on weekends может убрать некоторую сложность. Есть ли место, где смена часового пояса не происходит в выходные?
Спасибо за вашу помощь. (1) не проблема (особенно потому, что, как вы заметили, задача не запускается по выходным). О (2) Я думаю, что вижу концептуальную проблему, но не вижу практической; он по-прежнему будет последовательным и будет запускаться каждый день в запрошенное время, верно?
(2) будет проблемой, если запланированное время таково, что локальное «сегодня» не совпадает с «UTC сегодня» в то время, когда задача предназначена для запуска. В предыдущем примере, если мы находимся в Нью-Йорке и наше запланированное время 22:00, то begin и scheduled всегда будут позже, чем now, и задача никогда не будет выполняться.
Я вижу сейчас. Вы предлагаете определить now с тем же часовым поясом, который я использую для self._day_time? Кроме того, возвращаясь к исходному вопросу, вы говорите, что я должен использовать pytz для получения «политических» часовых поясов, таких как pytz.timezone('Europe/Paris')?
(i) Да, верно, (ii) начиная с Python 3.9, лучше использовать zoneinfo: pytz находится в режиме обслуживания. docs.python.org/3/library/zoneinfo.html
Спасибо. Не могли бы вы опубликовать это как ответ на этот вопрос?
Ответы 2
zoneinfo (в Python >= 3.9) и pytz (сторонний модуль, который широко использовался до того, как zoneinfo был включен), обеспечивают легкий доступ к часовым поясам IANA, таким как "Europe/Paris", "America/Chicago" и т. д. и т. д. Эти спецификации часовых поясов, которые включают правила перехода на летнее время для подходящего места.
Построение объекта часового пояса таким образом и использование его в качестве атрибута tzinfo вашего self._day_time позволит вашему планировщику работать со временем, учитывающим правила перехода на летнее время. Вы используете datetime.datetime.combine, который по умолчанию использует tzinfo своего аргумента времени и применяет его к результату (документация): это именно то, что нам нужно здесь.
Например:
import datetime
import zoneinfo
t0 = datetime.time(11, 15, tzinfo=zoneinfo.ZoneInfo('Europe/Paris'))
# Combine this time with d0 (winter, no DST) and d1 (summer, DST in force)
d0 = datetime.date(2023, 1, 1)
d1 = datetime.date(2023, 7, 1)
print(datetime.datetime.combine(d0, t0))
print(datetime.datetime.combine(d1, t0))
который печатает:
2023-01-01 11:15:00+01:00
2023-07-01 11:15:00+02:00
Обратите внимание на смещения UTC в выходных данных: DST действительно учитывается по мере необходимости.
Судя по комментариям, задача не выполняется по выходным, поэтому здесь мы не рассматриваем сложность того, что должно/должно происходить в день перехода на летнее время. Это было бы проблематично с текущим кодом: как показывает ответ @FObersteiner, добавление положительного timedelta к дате и времени в часовом поясе с переходом на летнее время может парадоксальным образом привести к перемещению назад во времени, так что end будет раньше, чем begin!
Не имеет прямого отношения к вашему исходному вопросу, но в логике вашего кода важно, чтобы аргумент даты, указанный для combine, отражал день, в который вы хотите, чтобы событие произошло. Таким образом, этот код проблематичен при определенных обстоятельствах:
now = dt.datetime.now(dt.UTC)
today = now.date()
Например, представьте, что self._day_time было задано как time(22, 0, tzinfo=zoneinfo.ZoneInfo('America/NewYork').
Если сейчас 22:00 20.07.2023 в Нью-Йорке (а значит задача должна сработать), то в UTC 02:00 21.07.2023.
Итак, ваш today равен 2023-07-21, и, следовательно, ваши begin и scheduled по местному времени равны 2023-07-21 22:00. Это на 24 часа позже, чем должно быть.
Вместо этого today следует определять с использованием даты и времени с тем же часовым поясом, что и self._day_time.
не уверен, что это предотвращает проблемы, если задача запланирована на переход на летнее время. Допустим, переход происходит в 2 часа ночи, в году бывает два перехода (включение и выключение летнего времени), и выполнение задачи запланировано на 2 часа ночи. Разве вы не получите один день в году с двумя казнями и один день в этом году без казни?
Разве вы не получите один день в году с двумя казнями и один день в этом году без казни? Судя по комментариям (stackoverflow.com/questions/76719932/…), на практике это не проблема, так как задача не запускается по выходным. Я отредактирую, чтобы уточнить.
Вы уверены, что все переходы на летнее время происходят по выходным для всех часовых поясов, где есть летнее время? ;-)
@FObersteiner существуют правила, определяющие, какое время допустимо при переходе на летнее время. Время с именем часового пояса, а не смещением, уникально. Вы никогда не получите две казни 2023-10-29 03:30 at Europe/Athens
@FObersteiner Я исхожу из оговорки OP в комментариях, что эта проблема их не волнует.
Проблемы возникают, если вместо имени часового пояса используется смещение, поскольку локальное время выполнения сдвинется на 1 час. Однако повторных казней не будет.
Двойных казней действительно не будет. (В вопросе и комментариях вы увидите, что ОП изначально указывал, что задача должна выполняться дважды в день «отката», я заметил, что это не так, а затем ОП пояснил, что в конце концов это не проблема).
Я не совсем уверен, что это спасение. Это может быть нормально в рамках ограничений OP. Но имейте в виду, что вы можете создавать несуществующие даты и времени с помощью арифметики Python timedelta. Правила часового пояса здесь вас не защитят.
@FObersteiner Я думал, что Python достаточно умен, чтобы добавить временную дельту через границу летнего времени, но я проверил это и ошибся. Вам нужно преобразовать в UTC, добавить и преобразовать обратно.
Ответ @FObersteiner очень четко проясняет ситуацию. Slothrop, не могли бы вы обновить свой ответ, относящийся к этой проблеме? Я все равно приму этот ответ, поскольку он напрямую отвечает на мой вопрос.
конечно, обновил его, чтобы указать проблемы, которые могут возникнуть в день перехода на летнее время.
Вот иллюстрация к моему комментарию. Если вы планируете что-то только по времени, вас ждут сюрпризы, особенно если вы играете с арифметикой timedelta:
from datetime import datetime, timedelta
from zoneinfo import ZoneInfo
start = datetime(2023,10,29,1,45,tzinfo=ZoneInfo("Europe/Berlin"))
for i in range(10):
print(start+timedelta(minutes=i*20))
# 2023-10-29 01:45:00+02:00
# 2023-10-29 02:05:00+02:00
# 2023-10-29 02:25:00+02:00
# 2023-10-29 02:45:00+02:00
# 2023-10-29 03:05:00+01:00 # <<-- "naive timedelta arithmetic" is wrong !
# 2023-10-29 03:25:00+01:00
# 2023-10-29 03:45:00+01:00
# 2023-10-29 04:05:00+01:00
# 2023-10-29 04:25:00+01:00
# 2023-10-29 04:45:00+01:00
Как прокомментировал @MarkRansom, вам нужно будет преобразовать в UTC, прежде чем добавлять продолжительность:
def aware_add(dt, duration):
return (dt.astimezone(ZoneInfo("UTC")) + duration).astimezone(dt.tzinfo)
for i in range(10):
print(aware_add(start, timedelta(minutes=i*20)))
# 2023-10-29 01:45:00+02:00
# 2023-10-29 02:05:00+02:00
# 2023-10-29 02:25:00+02:00
# 2023-10-29 02:45:00+02:00 # <<-- after 2:59:59, 2:00:00 follows ...
# 2023-10-29 02:05:00+01:00 # <<-- note the duplicate times ...
# 2023-10-29 02:25:00+01:00 # only the combination of UTC offset and time is unique !
# 2023-10-29 02:45:00+01:00
# 2023-10-29 03:05:00+01:00
# 2023-10-29 03:25:00+01:00
# 2023-10-29 03:45:00+01:00
Спецификаторы часового пояса, такие как
"Europe/Paris","America/Chicago"и т. д., учитывают переход на летнее время в соответствующем месте. Таким образом, вы можете использовать любой из них в качестве своегоtzinfo. Некоторое внимание нужно уделить тому, как запустить задачу дважды в день «возврата»: объектtimeимеет атрибутfold, который используется для различения двух 2.30 в этот день.