Часть проблемы здесь заключается в том, что строки, обычно используемые для представления часовых поясов, на самом деле не уникальны. «EST» означает «Америка/Нью-Йорк» только для жителей Северной Америки. Это ограничение в C time API, и решение Python состоит в том, чтобы… добавить полные функции tz в какую-нибудь будущую версию в любой день, если кто-то захочет написать PEP.
Вы можете форматировать и анализировать часовой пояс как смещение, но при этом теряется информация о переходе на летнее/летнее время (например, вы не можете отличить "Америку/Феникс" от "Америка/Лос-Анджелес" летом) . Вы можете отформатировать часовой пояс как трехбуквенную аббревиатуру, но вы не можете проанализировать его обратно.
Если вам нужно что-то нечеткое и неоднозначное, но обычно то, что вам нужно, вам нужна сторонняя библиотека, такая как dateutil
.
Если вам нужно что-то действительно однозначное, просто добавьте фактическое имя tz к локальной строке даты и времени и разделите его на другом конце:
d = datetime.datetime.now(pytz.timezone("America/New_York"))
dtz_string = d.strftime(fmt) + ' ' + "America/New_York"
d_string, tz_string = dtz_string.rsplit(' ', 1)
d2 = datetime.datetime.strptime(d_string, fmt)
tz2 = pytz.timezone(tz_string)
print dtz_string
print d2.strftime(fmt) + ' ' + tz_string
Или… на полпути между этими двумя, вы уже используете библиотеку pytz
, которая может анализировать (в соответствии с некоторыми произвольными, но четко определенными правилами устранения неоднозначности) такие форматы, как «EST». Итак, если вы действительно хотите, вы можете оставить %Z
на стороне форматирования, затем вытащить его и проанализировать с помощью pytz.timezone()
, прежде чем передать остальное в strptime
.
person
abarnert
schedule
07.02.2013