Python pytz Zeitzone Funktion gibt eine Zeitzone, die von 9 Minuten

Aus irgendeinem Grund, den ich in der Lage noch nicht, um herauszufinden, ist aus, aus dem folgenden Code:Python pytz Zeitzone Funktion gibt eine Zeitzone, die von 9 Minuten

>>> from pytz import timezone 
>>> timezone('America/Chicago')

ich:

<DstTzInfo 'America/Chicago' LMT-1 day, 18:09:00 STD>

Wenn, nehme ich an, sollte ich:

<DstTzInfo 'America/Chicago' LMT-1 day, 18:00:00 STD>

... da ich nicht glaube, dass meine Zeitzone 6 Stunden und 9 Minuten weg von UTC.

Ich habe mir die source code for pytz angesehen, aber ich gebe zu, dass ich nicht genau in der Lage war herauszufinden, was schief läuft.

Ich habe andere Werte an die timezone()-Funktion übergeben, und die zurückgegebenen Werte scheinen korrekt zu sein. Aus irgendeinem Grund sind die für meine Zeitzone relevanten Informationen nicht korrekt.

Schließlich hat mein Mitarbeiter in dem Würfel neben mir bestätigt, dass die Funktion die richtige Zeitzoneninfo auf seinem Rechner zurückgibt.

Hat jemand eine Idee, warum meine Zeitzone ('America/Chicago') um 9 Minuten ausgeschaltet wäre? Ich verwende die Version 2015.7 von pytz installiert mit pip. Vielen Dank!

Quelle

2016-02-17 elethan

Sie die mittlere Ortszeit http bekommen://stackoverflow.com/questions/11473721/weird-timezone-issue-with-pytz' tz = Zeitzone ('Amerika/Chicago'); tz.localize (datetime.datetime.now()) ' –

@PadraicCunningham, das scheint definitiv, was ich erlebe. Irgendeine Idee, warum derselbe Code auf der Maschine des Kerls neben mir ein anderes Ergebnis obwohl bekommt? – elethan

Verwenden Sie beide das gleiche Betriebssystem? –

Wenn Ihre lokale Zeitzone keinen festen UTC-Offset hat, ist es sinnlos, über ihren spezifischen Wert zu sprechen, ohne ein bestimmtes Datum/eine bestimmte Uhrzeit anzugeben.

Wenn Sie die Zeit zum Beispiel liefern, dann wird die aktuelle Zeit, die Sie, dass pytz sehen werden erzeugt die erwartete UTC-Offset:

>>> from datetime import datetime 
>>> import pytz 
>>> datetime.now(pytz.timezone('America/Chicago')).strftime('%Z%z') 
'CST-0600'

Siehe

Wenn Sie keine spezif ic date/time kann pytz einen beliebigen utc-Versatz aus der Menge der verfügbaren utc-Offsets für die angegebene Zeitzone zurückgeben. Die letzten pytz Versionen geben utc Offsets zurück, die dem frühesten Zeitpunkt entsprechen (LMT in der Regel), aber Sie sollten sich nicht darauf verlassen. Sie und Ihr Freund verwenden möglicherweise verschiedene Pytz-Versionen, die den Unterschied in den Ergebnissen erklären können.

Quelle

2016-02-17 18:36:16 jfs

Ich ging davon aus, dass diese Lösung funktionieren würde und markierte sie als korrekt, bevor ich herausfand, wie ich auf meine Kollegen-Version von 'pytz' herunterstufen kann. Jetzt habe ich die exakt gleiche Version wie er, aber von einer interaktiven Eingabeaufforderung aus erhalten wir unterschiedliche Ergebnisse aus dem Aufruf von 'pytz.timezone ('America/Chicago')' (dh ich bekomme '18: 09: 00', er bekommt '18: 00: 00'. Eine Idee, was könnte sonst für diese Diskrepanz verantwortlich sein, wenn es nicht die 'pytz'-Version ist? Könnte es ein Systemlevel Konfigurationsunterschied sein? – elethan

@elethan: der Code in der Antwort funktioniert muss "CST-0600" erzeugen, sonst ist das Setup kaputt. Bitte beachten Sie die Wörter: "sinnlos", "sollte nicht vertrauen" in der Antwort - Sie müssen das Datum/die Uhrzeit angeben, zB wie im Beispielcode gezeigt – jfs

Der Code in Ihrer Antwort funktioniert. Mein Problem ist, dass der Aufruf von 'pytz.timezone ('Amerika/Chicago') 'immer' 'auf meiner Maschine, und gibt immer' 'auf jeder anderen Maschine, auf der ich es getestet habe (sogar mit der gleichen Version von' pytz') und mein in Die Hauptfrage war, was den Unterschied ausmacht. Ich habe von Ihrer Antwort ausgegangen, dass es durch einen Unterschied in den Versionen verursacht wurde, aber das scheint nicht der Fall zu sein. – elethan

Nur weil meine Neugierde nicht genau befriedigt war, habe ich mich in letzter Zeit ein wenig mehr mit diesem Problem beschäftigt.

Anfangs schien es, dass der Unterschied von verschiedenen Versionen pytz stammte. Nachdem ich jedoch meine Version von pytz zu einer Version heruntergestuft hatte, in der ich bestätigt hatte, dass ich ein anderes Ergebnis als das auf meinem Computer hatte, stellte ich fest, dass dies nicht die Wurzel des Problems war: sogar mit der gleichen Version von pytz schien meine Maschine verwendet einen UTC-Offset basierend auf LMT, während die anderen Maschinen einen basierend auf CDT oder CST verwendeten.

Basierend auf meiner Konversation mit @ J.F.Sebastian nahm ich an, dass die einzige andere wahrscheinliche Möglichkeit ein Systemlevelunterschied war.Ich grub in den Quellcode pytz ein wenig mehr und fand, dass die Datei, in der pytz mindestens einige seiner Zeitzoneninformationen von bekommt, in /usr/share/zoneinfo/ ist. Also schaute ich auf die Datei /usr/share/zoneinfo/America/Chicago und obwohl es eine Binärdatei ist, ist ein Teil davon lesbar. Auf halbem Weg durch die Datei gibt es eine Liste von Zeitzonen: LMTCDTCSTESTCWTCPT. Wie Sie sehen können, LMT ist der erste Name in der Liste, und wie @ J.F.Sebastian vorgeschlagen, scheint das derjenige zu sein, der pytz in der in meiner ursprünglichen Frage beschriebenen Situation verwendet.

So sieht die Liste in Ubuntu 15.10 aus. In früheren Versionen von Ubuntu (z. B. Trusty und Precise), in denen ich das Ergebnis -600 anstelle von -609 erhalten habe, lautet die gleiche Liste CDTCSTESTCWTCPT.

Ich gebe zu, dass dies von vielen blinden Erkundungen und halbem Verständnis herrührt, aber es scheint so zu sein, dass dies für die Unterschiede verantwortlich ist, die ich auf allen Maschinen sah. Was die Gründe dafür angeht, warum die zoneinfo Dateien sich von Version zu Version unterscheiden und was diese Unterschiede für Ubuntu bedeuten, habe ich keine Ahnung, aber ich dachte, ich würde meine Erkenntnisse für diejenigen teilen, die ähnlich neugierig sind und möglicherweise aufschlussreiche Korrekturen/ergänzende Informationen von der Gemeinschaft.

Quelle

2016-03-03 17:52:39 elethan

Hinweis: Die Aktie 'Pytz' verwendet ein gebündeltes' zoneinfo' (Unterverzeichnis). Wenn Sie sehen, dass '/ usr/share/zoneinfo' verwendet wird; es bedeutet, dass Sie ein modifiziertes 'pytz'-Paket verwenden (zB wenn Sie' pytz' mit 'sudo apt-get python-tz' installiert haben, dann verwendet' pytz' 'open_resource()' gepatcht in Debian, um das System zoneinfo zu verwenden aus dem tzdata-Paket). Es ist schlecht, wenn der Bestand und die gepatchten Versionen die gleiche '__version__',' pytz.OLSON_VERSION' haben, aber Sie sollten nicht überrascht sein, dass sie unterschiedliche Ergebnisse produzieren (die gepatchte Version liegt wahrscheinlich über OLSON_VERSION, dh das System kann ein neuere tzdata-Version). – jfs

Wie Sie erwähnen gibt es einige Unterschiede in der Originaldatei in das pytz Modul: (in meinem Fall die Zentral Zeit verwenden)

xxxx ...... lib/python2.7/site-packages/pytz/zoneinfo/US/Zentral

In [66]: start = start.replace(tzinfo=central) 
 

 
In [67]: start.isoformat() 
 
Out[67]: '2018-02-26T00:00:00-05:51'

, wenn Sie die Standard-Datei des OS verwenden (ich in mac getestet, ubuntu und centOS)

/usr/share/zoneinfo/US/Zentral

mv xxxx...../lib/python2.7/site-packages/pytz/zoneinfo/US/Central xxxx...../lib/python2.7/site-packages/pytz/zoneinfo/US/Central-bak 
 

 
ln -s /usr/share/zoneinfo/US/Central xxxx...../lib/python2.7/site-packages/pytz/zoneinfo/US/Central

Das Problem behoben ist

In [7]: central = timezone('US/Central') 
 

 
In [8]: central 
 
Out[8]: <DstTzInfo 'US/Central' CST-1 day, 18:00:00 STD> 
 

 
In [10]: start = start.replace(tzinfo=central) 
 

 
In [11]: start.isoformat() 
 
Out[11]: '2018-02-27T00:00:00-06:00'

Quelle

2018-02-27 22:11:27

Python pytz Zeitzone Funktion gibt eine Zeitzone, die von 9 Minuten

Antwort

Verwandte Themen