Почему pytz localize() не создает объект datetime с tzinfo, соответствующим объекту tz, который его локализовал?

Есть ли кто-нибудь, кто может помочь мне понять, что здесь происходит?

import pytz
from datetime import datetime
tz = pytz.timezone('Europe/Berlin')
print repr(tz)
# <DstTzInfo 'Europe/Berlin' LMT+0:53:00 STD>
dt = datetime(2011, 1, 3, 18, 40)
result = tz.localize(dt)
print repr(result.tzinfo)
# <DstTzInfo 'Europe/Berlin' CET+1:00:00 STD>
assert result.tzinfo == tz, "Why aren't these the same timezone?"

Насколько я понимаю, метод localize() для объекта часового пояса pytz будет принимать наивный объект datetime и добавлять свойство tzinfo, которое соответствует объекту часового пояса, выполняющему локализацию. Похоже, что в данном случае этого не происходит.

Ясно, что я что-то неправильно понимаю о часовых поясах или о том, как pytz обрабатывает часовые пояса. Кто-нибудь может объяснить?


python datetime timezone pytz tzinfo
person bjmc    schedule 23.06.2014    source источник

Ответы (1)


arrow_upward
12
arrow_downward

Они находятся в одном часовом поясе – "Europe/Berlin".

Когда вы печатаете их, выходные данные включают аббревиатуру и смещение, которые применяются в данный конкретный момент времени.

Если вы изучите источники данных tz, вы увидите:

# Zone  NAME            GMTOFF   RULES       FORMAT   [UNTIL]
Zone    Europe/Berlin   0:53:28  -           LMT      1893 Apr
                        1:00     C-Eur       CE%sT    1945 May 24 2:00
                        1:00     SovietZone  CE%sT    1946
                        1:00     Germany     CE%sT    1980
                        1:00     EU          CE%sT

Таким образом, может показаться, что, когда часовой пояс не локализовал дату и время, он просто использует первую запись.

Также может показаться, что pytz не сохраняет дополнительные 28 секунд от исходного отклонения среднего местного времени, но это не имеет значения, если вы не работаете с датами в Берлине до апреля 1893 года.

person Matt Johnson-Pint    schedule 23.06.2014
comment
Спасибо за ваш комментарий. Хороший улов на CET/CEST. Это был плохой копипаст с моей стороны (теперь отредактированный). Я экспериментировал как с датой перехода на летнее время, так и с датой без перехода на летнее время. Я попытался запустить это под Python 3.4 с новейшим pytz и получил тот же результат. См.: gist.github.com/bjmc/59d8650ae3d2aebb7584 Ваша информация об источнике данных tz оценил. Означает ли это, что атрибут tzinfo [современной] локализованной даты никогда не будет сравниваться с абстрактным объектом часового пояса из pytz? - person bjmc; 24.06.2014
comment
В общем, я бы не стал считать, что tzinfo когда-либо можно было сравнить с другим tzinfo без учета конкретной даты и времени. Однако, если вы знаете, что оба объекта получены из pytz (или из tzlocal), вы можете сравнить их свойства .zone, которые содержат только строку идентификатора зоны ("Europe/Berlin"). - person Matt Johnson-Pint; 24.06.2014
comment
Не уверен, что это ответ. Он просто повторяет, что это проблема. Проблема возникает, когда вы пытаетесь заменить tzinfo объекта datetime. - person Peter Bengtsson; 04.12.2015
comment
@PeterBengtsson - Тогда не используйте замену, используйте localize. Вопрос заключался в том, чтобы понять, почему это происходит, поэтому этот ответ был сформулирован так. - person Matt Johnson-Pint; 04.12.2015
comment
@MattJohnson Теперь я понял. Хитрость заключается в том, чтобы всегда использовать localize(). Даже если это означает, что вам нужно сначала преобразовать его в часовой пояс naive datetime, чтобы вы могли локализовать его обратно. - person Peter Bengtsson; 04.12.2015