2015-09-02 4 views
2
>>> import time 
>>> t=1440935442 
>>> time.strftime("%Y/%m/%d-%H:%M:%S %z",time.gmtime(t)) 
'2015/08/30-11:50:42 +0000' 
>>> time.strftime("%Y/%m/%d-%H:%M:%S %z",time.localtime(t)) 
'2015/08/30-13:50:42 +0000' 

Le décalage reste le même +0000, mais je pense '2015/08/30-13: 50: 42 0200'python time.strftime% z est toujours égale à zéro au lieu de décalage horaire

Le fuseau horaire est correct, que la commande interprète le capital% Z comme il devrait

>>> time.strftime("%Y/%m/%d-%H:%M:%S %Z",time.localtime(t)) 
'2015/08/30-13:50:42 CEST' 

oeuvres date Unix comme je veux

$ date -u --date @1440935442 +"%Y/%m/%d-%H:%M:%S %z" 
2015/08/30-11:50:42 +0000 
$ date --date @1440935442 +"%Y/%m/%d-%H:%M:%S %z" 
2015/08/30-13:50:42 +0200 
+0

Je vois le même résultat, mais note dans la documentation: « L'utilisation de% Z est maintenant dépréciée, mais l'évasion% z qui se développe pour le décalage heure/minute préféré n'est pas pris en charge par toutes les bibliothèques ANSI C. " –

+0

(Je ne vois rien d'autre qui devrait faire la même chose avec strftime, peut-être devriez-vous regarder le module datetime?) –

+0

comme je suis sur un système linux standard, je m'attends à ce que% z soit dans la bibliothèque ansi lib . Mais ça ne marche pas comme prévu. C'est un peu triste. Je vais regarder dans datetime, mais cela signifie probablement que tout mon code doit changer. – Gunstick

Répondre

0

As documented:

La plupart des fonctions définies dans ce module d'appel de la bibliothèque de la bibliothèque C fonctionnent avec le même nom. Il peut parfois être utile de consulter la documentation de la plate-forme , car la sémantique de ces fonctions varie selon les plateformes.

and:

directives supplémentaires peuvent être pris en charge sur certaines plates-formes, mais seulement ceux énumérés ici ont un sens normalisé par l'ANSI C. Pour voir l' ensemble complet de codes de format pris en charge sur votre plate-forme, consultez la documentation strftime (3).

...

L'utilisation de% Z est maintenant dépréciée, mais l'évasion% z qui se développe à la heure/minute préféré décalage est pas pris en charge par toutes les bibliothèques ANSI C.

time.strftime() utilise C strftime() et donc le comportement dépend de la plate-forme. %z devrait fonctionner sur POSIX mais %z may return the same result as %Z on Windows. %z n'est pas documentée sur Python 2 et, par conséquent, le module time doit renvoyer les retours C strftime() sur la plate-forme donnée sans aucune modification.

Le même code fonctionne en Python 3 sur ma machine:

>>> import time 
>>> t = 1440935442 
>>> time.strftime("%Z%z", time.gmtime(t)) 
'GMT+0000' 
>>> time.strftime("%Z%z", time.localtime(t)) 
'CEST+0200' 

Votre question semble être Python 2 spécifique:

>>> import time 
>>> t = 1440935442 
>>> time.strftime("%Z%z", time.gmtime(t)) 
'CET+0000' 
>>> time.strftime("%Z%z", time.localtime(t)) 
'CEST+0000' 

Note: time.strftime('%Z%z') retours 'CEST+0200' à la fois Python 2 et 3. La différence pourrait s'expliquer par l'absence de tm_zone, tm_gmtoff attributs dans Python < 3.3. Ni time.gmtime() ni time.localtime() fournissent des informations de fuseau horaire sur Python 2 (en dehors de tm_isdst c'est pourquoi time.gmtime() conduit à CET). time.strftime('%Z%z') utilise C localtime() et donc il peut fournir tm_zone, tm_gmtoff même sur Python 2.

Si vous avez besoin comportement portable et de prendre en charge les fuseaux horaires qui pourraient avoir différentes tzname, décalage horaire UTC dans le passé; vous pouvez utiliser des objets tzinfo pytz (par ex., Par l'intermédiaire tzlocal module) qui permettent d'accéder à la base de données de fuseau horaire historique:

>>> from datetime import datetime 
>>> import tzlocal # $ pip install tzlocal 
>>> datetime.fromtimestamp(1440935442, tzlocal.get_localzone()).strftime('%Z%z') 
'CEST+0200'