Existe-t-il une liste des fuseaux horaires Pytz?


660

Je voudrais savoir quelles sont toutes les valeurs possibles pour l'argument de fuseau horaire dans la bibliothèque Python pytz. Comment faire?


6
C'est drôle comment "GMT", "GMT + 0", "GMT-0", "GMT0", "Greenwich", "UCT", "UTC", "Universal" et "Zulu" signifient tous fondamentalement la même chose et pourtant il y a tellement d'entrées pour cela.
Joe Z.

43
GMT n'est pas identique à UTC. C'est une erreur courante.
PawelRoman

1
@PawelRoman: GMT peut signifier différentes choses dans un contexte différent. Il ne UTC moyenne , parfois , par exemple, les chaînes de temps de certificat ssl tels que acceptée nécessite GMT ( héritage). ssl.cert_time_to_second() ASN1_TIME_print()
jfs

3
@PawelRoman vous avez raison dans le sens où l'un est un fuseau horaire et l'autre est un standard. Mais au sens pratique auquel la plupart des gens pensent, les deux se réfèrent au même moment dans le temps.
voler

Réponses:


319

Vous pouvez répertorier tous les fuseaux horaires disponibles avec pytz.all_timezones:

In [40]: import pytz
In [41]: pytz.all_timezones
Out[42]: 
['Africa/Abidjan',
 'Africa/Accra',
 'Africa/Addis_Ababa',
 ...]

Il y a aussi pytz.common_timezones:

In [45]: len(pytz.common_timezones)
Out[45]: 403

In [46]: len(pytz.all_timezones)
Out[46]: 563

9
En plus de all_timezones, pytz fournit également common_timezones .
Mark Hildreth

3
pourquoi la Chine manque-t-elle?
Adders

4
La Chine utilise un seul fuseau horaire , dont le nom de fuseau horaire est 'Asia/Shanghai'.
unutbu

1
Cette expression montre le terrible résultat que pytz peut donner: (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()(le résultat n'est pas -28800). J'éviterai pytz— dateutil.tz fournit des fonctionnalités similaires mais utilise la base de données de fuseau horaire du système d'exploitation et n'a pas de tels problèmes.
Yongwei Wu

2
@YongweiWu, c'est une mauvaise utilisation de l'API. Vous ne devez pas passer directement un fuseau horaire pytz avec un décalage utc non fixe comme argument tzinfo. Utilisez la méthode .localize () comme le suggèrent les documents pytz.
jfs

38

Ne créez pas votre propre liste - pytza un ensemble intégré:

import pytz
set(pytz.all_timezones_set)  
>>> {'Europe/Vienna', 'America/New_York', 'America/Argentina/Salta',..}

Vous pouvez ensuite appliquer un fuseau horaire :

import datetime
tz = pytz.timezone('Pacific/Johnston')
ct = datetime.datetime.now(tz=tz)
>>> ct.isoformat()
2017-01-13T11:29:22.601991-05:00

Ou si vous avez déjà un datetimeobjet qui est conscient de TZ (pas naïf):

# 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

27

Le nom du fuseau horaire est le seul moyen fiable de spécifier le fuseau horaire.

Vous pouvez trouver une liste de noms de fuseau horaire ici: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones Notez que cette liste contient beaucoup de noms d'alias, tels que US / Eastern pour le fuseau horaire qui est correctement appelé America / New_York.

Si vous souhaitez créer cette liste par programme à partir de la base de données zoneinfo, vous pouvez la compiler à partir du fichier zone.tab dans la base de données zoneinfo. Je ne pense pas que pytz ait une API pour les obtenir, et je ne pense pas non plus que ce serait très utile.


14

Ici, liste Python des codes de pays, noms, continents, capitales et fuseaux horaires pytz.

countries = [
{'timezones': ['Europe/Paris'], 'code': 'FR', 'continent': 'Europe', 'name': 'France', 'capital': 'Paris'}
{'timezones': ['Africa/Kampala'], 'code': 'UG', 'continent': 'Africa', 'name': 'Uganda', 'capital': 'Kampala'},
{'timezones': ['Asia/Colombo'], 'code': 'LK', 'continent': 'Asia', 'name': 'Sri Lanka', 'capital': 'Sri Jayewardenepura Kotte'},
{'timezones': ['Asia/Riyadh'], 'code': 'SA', 'continent': 'Asia', 'name': 'Saudi Arabia', 'capital': 'Riyadh'},
{'timezones': ['Africa/Luanda'], 'code': 'AO', 'continent': 'Africa', 'name': 'Angola', 'capital': 'Luanda'},    
{'timezones': ['Europe/Vienna'], 'code': 'AT', 'continent': 'Europe', 'name': 'Austria', 'capital': 'Vienna'},
{'timezones': ['Asia/Calcutta'], 'code': 'IN', 'continent': 'Asia', 'name': 'India', 'capital': 'New Delhi'},
{'timezones': ['Asia/Dubai'], 'code': 'AE', 'continent': 'Asia', 'name': 'United Arab Emirates', 'capital': 'Abu Dhabi'},
{'timezones': ['Europe/London'], 'code': 'GB', 'continent': 'Europe', 'name': 'United Kingdom', 'capital': 'London'},
]

Pour la liste complète: Gist Github

J'espère que cela aide.



4

EDIT: Je vous serais reconnaissant si vous ne votez pas plus bas cette réponse. Cette réponse est fausse , mais je préfère la conserver comme note historique. Bien qu'il soit discutable que l'interface pytz soit sujette aux erreurs, elle peut faire des choses que dateutil.tz ne peut pas faire, en particulier en ce qui concerne l'heure d'été dans le passé ou dans le futur. J'ai honnêtement enregistré mon expérience dans un article "Fuseaux horaires en Python" .


Si vous êtes sur une plate-forme de type Unix, je vous suggère d'éviter pytz et de regarder juste / usr / share / zoneinfo. dateutil.tz peut utiliser ces informations.

Le morceau de code suivant montre le problème que pytz peut poser. J'ai été choqué quand je l'ai découvert. (Curieusement, le pytz installé par yum sur CentOS 7 ne présente pas ce problème.)

import pytz
import dateutil.tz
from datetime import datetime
print((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())
print((datetime(2017,2,13,14,29,29, tzinfo=dateutil.tz.gettz('Asia/Shanghai'))
     - datetime(2017,2,13,14,29,29, tzinfo=dateutil.tz.tzutc()))
     .total_seconds())

-29160.0
-28800.0

C'est-à-dire que le fuseau horaire créé par pytz correspond à l'heure locale vraie, au lieu de l'heure locale standard que les gens observent. Shanghai est conforme à +0800 et non à +0806 comme suggéré par pytz:

pytz.timezone('Asia/Shanghai')
<DstTzInfo 'Asia/Shanghai' LMT+8:06:00 STD>

EDIT: Merci au commentaire et au downvote de Mark Ransom, maintenant je sais que j'utilise pytz dans le mauvais sens. En résumé, vous n'êtes pas censé transmettre le résultat de pytz.timezone(…)à datetime, mais devez transmettre le datetimeà sa localizeméthode.

Malgré son argument (et mon mal de ne pas avoir lu la documentation pytz plus attentivement), je vais garder cette réponse. Je répondais à la question dans un sens (comment énumérer les fuseaux horaires pris en charge, mais pas avec pytz), car je pensais que pytz n'avait pas fourni de solution correcte. Bien que ma croyance soit fausse, cette réponse fournit toujours des informations, à mon humble avis, qui sont potentiellement utiles aux personnes intéressées par cette question. La manière correcte de faire de Pytz est contre-intuitive. Heck, si le tzinfo créé par pytz ne doit pas être utilisé directement par datetime, il doit être d'un type différent. L'interface pytz est tout simplement mal conçue. Le lien fourni par Mark montre que de nombreuses personnes, pas seulement moi, ont été induites en erreur par l'interface pytz.


2
Voir stackoverflow.com/questions/11473721/… pour un correctif. Il n'y a rien de mal à cela pytz, vous l'utilisez mal. PS Ce n'est pas une réponse à la question du tout .
Mark Ransom

1
@MarkRansom Bonne info, et c'est agréable à savoir. Cependant, je n'achète pas votre argument. L'interface est mal conçue, point final. C'est très contre-intuitif.
Yongwei Wu

3
Oui, l'interface est mal conçue. Mais c'est l' datetimeinterface qui ne va pas pytz. datetimen'a pas anticipé les objets de fuseau horaire intelligents , donc son interface ne les initialise pas correctement.
Mark Ransom

1
Avec égards, je ne suis pas d'accord. datetimefait partie de la bibliothèque Python standard, et c'est pytz qui devrait suivre l' datetimeinterface, et non l'inverse. Si quelqu'un pouvait implémenter une interface comme il le pense mieux sans consensus, il n'y aurait pas de logiciel robuste.
Yongwei Wu

2
Comme je l'ai dit, je pytzne peux pas suivre l' datetimeinterface car l' datetimeinterface est déficiente. Les auteurs de cette interface n'ont pas anticipé les problèmes d'un fuseau horaire dont les paramètres changent au fil des ans. Ce n'est pas parce qu'il fait partie de la distribution Python standard qu'il est parfait.
Mark Ransom

-8

À mon avis, c'est un défaut de conception de la bibliothèque pytz. Il devrait être plus fiable de spécifier un fuseau horaire en utilisant le décalage, par exemple

pytz.construct("UTC-07:00")

ce qui vous donne le fuseau horaire Canada / Pacifique.


12
Les décalages changent tout au long de l'année (généralement en raison de l'heure d'été), ce n'est donc pas la même chose que ce que nous considérons normalement comme un fuseau horaire.
Ryan Hiebert

La syntaxe choisie est basée sur les définitions de tzdata .
Brad Koch
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.