Не уверен относительно ожидаемого поведения в вычислениях datetime, но я просто объясню поведение из примеров общего кода.
pytz.localize
создает экземпляр datetime с учетом часового пояса. Когда часовой пояс Нью-Йорка используется для localize
простого времени, он назначает правильный часовой пояс, EDT
до 3 ноября и EST
для 4 ноября и позже. Давайте исключим timedelta
здесь:
>>> import pytz
>>> from datetime import datetime, timedelta
>>> tz_ny = pytz.timezone("America/New_York")
>>> tz_ny.localize(datetime(2019, 11, 3))
datetime.datetime(2019, 11, 3, 0, 0, tzinfo=<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>)
>>> tz_ny.localize(datetime(2019, 11, 4))
datetime.datetime(2019, 11, 4, 0, 0, tzinfo=<DstTzInfo 'America/New_York' EST-1 day, 19:00:00 STD>)
Как видно, DstTzInfo
отличаются, как и следовало ожидать, потому что NY DST заканчивается 3 ноября.
Образец общего кода создаетstart
по localizing
3 ноября, который присваивает EDT
как tzinfo
объекту datetime (с использованием DST). Для создания end
, timedelta
из 1 дня добавляется к start
, но tzinfo
объекта datetime
остается неизменным :
>>> start = tz_ny.localize(datetime(2019, 11, 3))
>>> start.tzinfo
<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>
>>> end = start + timedelta(days=1)
>>> end.tzinfo
<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>
Такend
означает datetime
для 4 ноября, но информация DstTzInfo
остается такой же, как 3 ноября. И это отличается от localizing
наивного datetime
от 4 ноября, который не использует DST.