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

Question

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

Answer 1

Vous pouvez lister 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 existe également pytz.common_timezones :

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

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

Answer 2

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

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

Vous pouvez alors 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 datetime objet c'est-à-dire TZ aware (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

Answer 3

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

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

Si vous voulez créer cette liste de manière programmatique à 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.

Answer 4

Voici une liste Python des codes de pays, des noms, des continents, des capitales et des 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, voir ceci GitHub Gist .

Answer 5

EDIT : J'apprécierais que vous ne décrédibilisiez pas davantage cette réponse. Cette réponse est mauvais mais je préfère le conserver comme une note historique. Bien que l'on puisse discuter du fait que l'interface pytz soit sujette à des erreurs, elle peut faire des choses que dateutil.tz ne peut pas faire, notamment en ce qui concerne l'heure d'été dans le passé ou dans le futur. J'ai honnêtement consigné mon expérience dans un article "Fuseaux horaires en Python" .

---

Si vous êtes sur une plateforme de type Unix, je vous suggère d'éviter pytz et de regarder simplement dans /usr/share/zoneinfo. dateutil.tz peut utiliser les informations qui s'y trouvent.

Le morceau de code suivant montre le problème que peut poser pytz. J'ai été choqué lorsque je l'ai découvert pour la première fois. (Il est intéressant de noter que 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 à la véritable heure locale, 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>

EDITAR: Grâce au commentaire et au downvote de Mark Ransom, je sais maintenant que j'utilise pytz de la mauvaise façon. En résumé, vous n'êtes pas supposé passer le résultat de pytz.timezone(…) a datetime mais devrait passer le datetime à son localize méthode.

Malgré son argument (et mon tort de ne pas avoir lu plus attentivement la documentation de pytz), je vais conserver cette réponse. Je répondais à la question d'une manière (comment énumérer les fuseaux horaires supportés, mais pas avec pytz), parce que je pensais que pytz ne fournissait pas une solution correcte. Bien que ma conviction était erronée, cette réponse fournit quand même des informations, IMHO, qui sont potentiellement utiles aux personnes intéressées par cette question. La réponse de Pytz correct la façon de faire les choses est contre-intuitive. Heck, si le tzinfo créé par pytz ne doit pas être utilisé directement par datetime il devrait être d'un type différent. L'interface de pytz est tout simplement mal conçue. Le lien fourni par Mark montre que de nombreuses personnes, et pas seulement moi, ont été trompées par l'interface pytz.