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.
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é:
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
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.
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.)
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:
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.
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.
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 .
ssl.cert_time_to_second()
ASN1_TIME_print()
Réponses:
Vous pouvez répertorier tous les fuseaux horaires disponibles avec
pytz.all_timezones
:Il y a aussi
pytz.common_timezones
:la source
all_timezones
, pytz fournit égalementcommon_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()
(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.Ne créez pas votre propre liste -
pytz
a un ensemble intégré:Vous pouvez ensuite appliquer un fuseau horaire :
Ou si vous avez déjà un
datetime
objet qui est conscient de TZ (pas naïf):la source
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.
la source
Ici, liste Python des codes de pays, noms, continents, capitales et fuseaux horaires pytz.
Pour la liste complète: Gist Github
J'espère que cela aide.
la source
Ils semblent être remplis par les fuseaux horaires de la base de données tz trouvés ici .
la source
pytz
donne accès à la base de données tz (c'est la source des données wikipedia).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.)
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:
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 ledatetime
à salocalize
mé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.la source
pytz
, vous l'utilisez mal. PS Ce n'est pas une réponse à la question du tout .datetime
interface qui ne va paspytz
.datetime
n'a pas anticipé les objets de fuseau horaire intelligents , donc son interface ne les initialise pas correctement.datetime
fait partie de la bibliothèque Python standard, et c'est pytz qui devrait suivre l'datetime
interface, 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.pytz
ne peux pas suivre l'datetime
interface car l'datetime
interface 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.À 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
ce qui vous donne le fuseau horaire Canada / Pacifique.
la source