Забавно, что «GMT», «GMT + 0», «GMT-0», «GMT0», «Гринвич», «UCT», «UTC», «Universal» и «Zulu» означают в основном одно и то же и все же есть так много записей для этого.
Джо З.
43
GMT не совпадает с UTC. Это распространенная ошибка.
PawelRoman
1
@PawelRoman: GMT может означать разные вещи в другом контексте. Это делает средний UTC иногда , например, SSL - сертификат времени строки , такие как принято требует GMT ( наследство). ssl.cert_time_to_second()ASN1_TIME_print()
JFS
3
@PawelRoman вы правы в том смысле, что один является часовым поясом, а другой - стандартом. Но в практическом смысле, о котором думают большинство людей, оба ссылаются на один и тот же момент времени.
Китай использует один часовой пояс, название которого называется часовой пояс 'Asia/Shanghai'.
unutbu
1
Это выражение показывает ужасный результат, который может дать pytz : (datetime(2017,2,13,14,29,29, tzinfo=pytz.timezone('Asia/Shanghai')) - datetime(2017,2,13,14,29,29, tzinfo=pytz.timezone('UTC'))).total_seconds()(результат не -28800). Я буду избегать pytz—dateutil.tz предоставляет аналогичные функции, но использует базу данных часового пояса ОС и не имеет таких проблем.
Yongwei Wu
2
@YongweiWu это неправильное использование API. Вы не должны напрямую передавать часовой пояс pytz с нефиксированным смещением utc в качестве аргумента tzinfo. Используйте метод .localize (), как предполагает документация pytz.
JFS
38
Не создавайте свой собственный список - pytzимеет встроенный набор:
Или, если у вас уже есть datetimeобъект, который знает TZ (не наивный):
# This timestamp is in UTC
my_ct = datetime.datetime.now(tz=pytz.UTC)# Now convert it to another timezone
new_ct = my_ct.astimezone(tz)>>> new_ct.isoformat()2017-01-13T11:29:22.601991-05:00
Название часового пояса - единственный надежный способ указать часовой пояс.
Вы можете найти список названий часовых поясов здесь: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Обратите внимание, что этот список содержит много псевдонимов, например, US / Eastern для часового пояса, который правильно называется America / New_York.
Если вы программно хотите создать этот список из базы данных zoneinfo, вы можете скомпилировать его из файла zone.tab в базе данных zoneinfo. Я не думаю, что у pytz есть API для их получения, и я также не думаю, что это было бы очень полезно.
pytzобеспечивает доступ к базе данных tz (это источник данных Википедии).
Jfs
4
РЕДАКТИРОВАТЬ: Я был бы признателен, если вы не понизить этот ответ дальше. Этот ответ неверный , но я бы предпочел оставить его в качестве исторической заметки. Хотя можно утверждать, что интерфейс pytz подвержен ошибкам, он может делать то, чего не может делать dateutil.tz, особенно в отношении перехода на летнее время в прошлом или в будущем. Я честно записал свой опыт в статье «Часовые пояса в Python» .
Если вы работаете на Unix-подобной платформе, я бы посоветовал вам избегать pytz и просто посмотрите на / usr / share / zoneinfo. dateutil.tz может использовать информацию там.
Следующий фрагмент кода показывает проблему, которую может дать pytz. Я был шокирован, когда впервые узнал об этом. (Интересно, что pytz, установленный yum на CentOS 7, не имеет этой проблемы.)
Т.е. часовой пояс, созданный pytz, соответствует истинному местному времени, а не стандартному местному времени, которое люди наблюдают. Шанхай соответствует +0800, а не +0806, как предполагает pytz:
РЕДАКТИРОВАТЬ: Благодаря комментарию Марка Рэнсома и downvote, теперь я знаю, что я использую pytz неправильно. Таким образом, вы не должны передавать результат pytz.timezone(…)в datetime, но должны передавать datetimeего localizeметод.
Несмотря на его аргумент (и мое плохое за то, что я не читаю документацию pytz более внимательно), я собираюсь сохранить этот ответ. Я отвечал на вопрос одним способом (как перечислить поддерживаемые часовые пояса, хотя и не с помощью pytz), потому что я полагал, что pytz не дал правильного решения. Хотя мое мнение было неверным, этот ответ по-прежнему предоставляет некоторую информацию, ИМХО, которая потенциально полезна для людей, заинтересованных в этом вопросе. Правильный способ Pytz делать вещи нелогично . Черт, если tzinfo, созданная pytz , не должна использоваться напрямую datetime, это должен быть другой тип. Интерфейс pytz просто плохо разработан. Ссылка, предоставленная Марком, показывает, что многие люди, не только я, были введены в заблуждение интерфейсом pytz.
См. Stackoverflow.com/questions/11473721/… для исправления. Там нет ничего плохого pytz, вы просто используете это неправильно. PS Это не ответ на вопрос вообще .
Марк Рэнсом
1
@MarkRansom Хорошая информация, и это приятно знать. Тем не менее, я не покупаю ваш аргумент. Интерфейс разработан неправильно, точка. Это очень нелогично.
Yongwei Wu
3
Да, интерфейс спроектирован неправильно. Но это datetimeинтерфейс, который не так, не так pytz. datetimeне ожидал интеллектуальных объектов часового пояса, поэтому его интерфейс не инициализирует их должным образом.
Марк Рэнсом
1
С уважением я не согласен. datetimeявляется частью стандартной библиотеки Python, и именно pytz должен следовать datetimeинтерфейсу, а не наоборот. Если бы кто-то мог реализовать какой-либо интерфейс так, как он думает лучше, без консенсуса, не было бы надежного программного обеспечения.
Юнвэй Ву
2
Как я уже сказал, pytzне может следовать datetimeинтерфейсу, потому что datetimeинтерфейс неисправен. Авторы этого интерфейса не предвидели проблем с часовым поясом, параметры которого менялись с годами. Тот факт, что он является частью стандартного дистрибутива Python, не означает, что он идеален.
Марк Рэнсом
-8
На мой взгляд, это недостаток дизайна библиотеки Pytz. Надежнее указывать часовой пояс, используя смещение, например
pytz.construct("UTC-07:00")
который дает вам Канада / Тихоокеанский часовой пояс.
ssl.cert_time_to_second()
ASN1_TIME_print()
Ответы:
Вы можете перечислить все доступные часовые пояса с
pytz.all_timezones
:Также есть
pytz.common_timezones
:источник
all_timezones
, Pytz также обеспечиваетcommon_timezones
.'Asia/Shanghai'
.(datetime(2017,2,13,14,29,29, tzinfo=pytz.timezone('Asia/Shanghai')) - datetime(2017,2,13,14,29,29, tzinfo=pytz.timezone('UTC'))).total_seconds()
(результат не -28800). Я буду избегать pytz—dateutil.tz предоставляет аналогичные функции, но использует базу данных часового пояса ОС и не имеет таких проблем.Не создавайте свой собственный список -
pytz
имеет встроенный набор:Затем вы можете применить часовой пояс :
Или, если у вас уже есть
datetime
объект, который знает TZ (не наивный):источник
Название часового пояса - единственный надежный способ указать часовой пояс.
Вы можете найти список названий часовых поясов здесь: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones Обратите внимание, что этот список содержит много псевдонимов, например, US / Eastern для часового пояса, который правильно называется America / New_York.
Если вы программно хотите создать этот список из базы данных zoneinfo, вы можете скомпилировать его из файла zone.tab в базе данных zoneinfo. Я не думаю, что у pytz есть API для их получения, и я также не думаю, что это было бы очень полезно.
источник
Здесь представлен список кодов стран, имен, континентов, столиц и часовых поясов Python.
Для полного списка: Gist Github
Надеюсь, поможет.
источник
Похоже, они заполнены часовыми поясами базы данных tz, найденными здесь .
источник
pytz
обеспечивает доступ к базе данных tz (это источник данных Википедии).РЕДАКТИРОВАТЬ: Я был бы признателен, если вы не понизить этот ответ дальше. Этот ответ неверный , но я бы предпочел оставить его в качестве исторической заметки. Хотя можно утверждать, что интерфейс pytz подвержен ошибкам, он может делать то, чего не может делать dateutil.tz, особенно в отношении перехода на летнее время в прошлом или в будущем. Я честно записал свой опыт в статье «Часовые пояса в Python» .
Если вы работаете на Unix-подобной платформе, я бы посоветовал вам избегать pytz и просто посмотрите на / usr / share / zoneinfo. dateutil.tz может использовать информацию там.
Следующий фрагмент кода показывает проблему, которую может дать pytz. Я был шокирован, когда впервые узнал об этом. (Интересно, что pytz, установленный yum на CentOS 7, не имеет этой проблемы.)
Т.е. часовой пояс, созданный pytz, соответствует истинному местному времени, а не стандартному местному времени, которое люди наблюдают. Шанхай соответствует +0800, а не +0806, как предполагает pytz:
РЕДАКТИРОВАТЬ: Благодаря комментарию Марка Рэнсома и downvote, теперь я знаю, что я использую pytz неправильно. Таким образом, вы не должны передавать результат
pytz.timezone(…)
вdatetime
, но должны передаватьdatetime
егоlocalize
метод.Несмотря на его аргумент (и мое плохое за то, что я не читаю документацию pytz более внимательно), я собираюсь сохранить этот ответ. Я отвечал на вопрос одним способом (как перечислить поддерживаемые часовые пояса, хотя и не с помощью pytz), потому что я полагал, что pytz не дал правильного решения. Хотя мое мнение было неверным, этот ответ по-прежнему предоставляет некоторую информацию, ИМХО, которая потенциально полезна для людей, заинтересованных в этом вопросе. Правильный способ Pytz делать вещи нелогично . Черт, если tzinfo, созданная pytz , не должна использоваться напрямую
datetime
, это должен быть другой тип. Интерфейс pytz просто плохо разработан. Ссылка, предоставленная Марком, показывает, что многие люди, не только я, были введены в заблуждение интерфейсом pytz.источник
pytz
, вы просто используете это неправильно. PS Это не ответ на вопрос вообще .datetime
интерфейс, который не так, не такpytz
.datetime
не ожидал интеллектуальных объектов часового пояса, поэтому его интерфейс не инициализирует их должным образом.datetime
является частью стандартной библиотеки Python, и именно pytz должен следоватьdatetime
интерфейсу, а не наоборот. Если бы кто-то мог реализовать какой-либо интерфейс так, как он думает лучше, без консенсуса, не было бы надежного программного обеспечения.pytz
не может следоватьdatetime
интерфейсу, потому чтоdatetime
интерфейс неисправен. Авторы этого интерфейса не предвидели проблем с часовым поясом, параметры которого менялись с годами. Тот факт, что он является частью стандартного дистрибутива Python, не означает, что он идеален.На мой взгляд, это недостаток дизайна библиотеки Pytz. Надежнее указывать часовой пояс, используя смещение, например
который дает вам Канада / Тихоокеанский часовой пояс.
источник