Python: Comment faire pour obtenir une valeur de type datetime.aujourd'hui() qui est “timezone conscient”?

Je suis en train de soustraire une date de valeur à partir de la valeur de datetime.today() de calculer combien de temps il y a quelque chose a été. Mais il se plaint:

TypeError: can't subtract offset-naive and offset-aware datetimes

La valeur datetime.today() ne semble pas être le "fuseau horaire courant", tandis que mon autre valeur à la date de l'est. Comment puis-je obtenir une valeur de datetime.today() qui est le fuseau horaire courant? Maintenant, c'est de me donner l'heure en heure locale, qui se trouve être PST, c'est à dire UTC-8 heures. Pire des cas, est il possible que je peux entrer manuellement une valeur de timezone dans le datetime objet renvoyé par datetime.today() et réglez-UTC-8? Bien sûr, l'idéal serait pour elle de connaître automatiquement le fuseau horaire.

InformationsquelleAutor mindthief | 2010-12-25
  1. 313

    Dans la bibliothèque standard, il n'y a pas de croix-plate-forme de manière à créer au courant de fuseaux horaires sans créer votre propre fuseau horaire classe.

    Sur Windows, il y a win32timezone.utcnow(), mais cela fait partie de pywin32. Je voudrais plutôt vous suggérons d'utiliser le pytz bibliothèque, qui a constamment mise à jour de la base de données de plus de fuseaux horaires.

    Le travail avec les fuseaux horaires peuvent être très délicat (voir "Autres lectures" liens ci-dessous), de sorte que vous pouvez plutôt souhaitez utiliser UTC tout au long de votre application, en particulier pour les opérations arithmétiques comme le calcul de la différence entre deux points dans le temps.

    Vous pouvez obtenir la date/heure actuelle comme suit:

    import pytz
from datetime import datetime
datetime.utcnow().replace(tzinfo=pytz.utc)

    L'esprit que datetime.today() et datetime.now() retour de la local temps, pas le temps UTC, donc l'application .replace(tzinfo=pytz.utc) pour eux ne serait pas correct.

    Une autre belle façon de le faire est:

    datetime.now(pytz.utc)

    qui est un peu plus court et fait de même.

    Lecture/regarder pourquoi préférer l'UTC, dans de nombreux cas:

    • Que diriez - datetime.now(pytz.utc) au lieu de datetime.utcnow().replace(tzinfo = pytz.utc) ?
    • Oui, ça marche aussi. Je vais l'ajouter à la réponse. merci
    • J'ai fini par enlever le fuseau horaire de sensibilisation dans le courant de la date en faisant d1.replace(tzinfo=None), puis à l'aide de datetime.utcnow() pour obtenir de l'heure UTC actuelle, et puis j'ai été en mesure de soustraire les deux heures correctement. Si, il ressemble à pytz est assez facile à utiliser. Je vais probablement passer à cette question dans un proche avenir, de sorte que je peux avoir plus de flexibilité dans mon application. Merci! 🙂
    • En fait, en supprimant le fuseau horaire de sensibilisation n'a pas beaucoup de sens. Python est capable de soustraire deux conscients instances datetime. Retrait d'informations sur le fuseau horaire peut vous donner des résultats erronés si vous travaillez avec plusieurs fuseaux horaires différents.
    • yep j'ai fait en sorte j'ai été en utilisant seulement UTC fois :). Même si bien sûr, avoir comme conscience, c'est certainement préférable, et je vais probablement passer à bientôt. C'est juste ce que j'ai fait pour le faire fonctionner avant que j'ai vu votre réponse.
    • now(utc) n'a pas de retour aujourd'hui (sauf si c'est à minuit UTC), il retourne l'heure courante au format UTC. Vous devez aussi .replace(hour=0, minute=0, ...) pour obtenir le début de la journée (comme datetime.today())
    • Le docs dire que today() renvoie l'heure actuelle, pas à minuit. Si il y a un cas d'utilisation où minuit est nécessaire, oui, le remplacement doit être fait en conséquence. Puisque la question initiale était d'environ datetime différence, je ne pense pas que minuit est nécessaire.
    • Mon commentaire implique que je pensais (à tort) que datetime.today() est combine(date.today(), time()). datetime a deux .now() et .today() méthodes (comme vous l'avez souligné à juste titre) de retour (presque) la même chose. Il n'y a pas de date.now() méthode. date et datetime les objets ne sont pas interchangeables. À l'aide d'un objet datetime au lieu d'un date objet peut produire des bogues subtils; je ne vois pas de raison pour datetime.today() à exister que si elle est un doublon de datetime.now().
    • En ajoutant à cette réponse, si vous arrive d'être en utilisant django, utilisez toujours timezone.now() au lieu de datetime.now() car il utilise UTC automatiquement si USE_TZ = True. timezone est de trouver à django.utils.timezone, de la documentation: docs.djangoproject.com/en/1.11/topics/i18n/timezones
    • votre montage est un non-sens et le résultat n'est pas "MAUVAIS" (sic). Il est parfaitement logique que si je travaille dans le Los Angeles time et j'ai ajouter les 90 jours de datetime dont le temps est 10H du soir, puis-je obtenir un datetime dont le temps est 10H du soir, même si je traverse une heure avancée de la frontière. C'est le tout le point de travail localisées dans le temps; c'est le résultat qui a de sens que si, par exemple, je suis de la génération des heures de réunion pour un club de Los Angeles. Existe-il des circonstances dans lesquelles cela n'est pas souhaitable? Certainement. Mais si je suis en train de faire de l'arithmétique avec localisées fuseaux horaires, c'est parce que je explicitement vouloir ce comportement.
    • Si j'étais vous, je voudrais revenir MrE de la modifier; comme je le note dans mon commentaire ci-dessus, je pense que ça n'a aucun sens et montre, tout simplement, précisément le comportement que vous attendez, tout en déclarant qu'il "MAUVAIS", sans explication. Mais c'est votre réponse, et vous êtes toujours actif ici, je vais donc laisser le choix à vous.
    • peut-être qu'il n'est pas "MAL", dans votre cas d'utilisation, l'ajout de jours. mais essayez d'ajouter des heures, et généralement ce n'est pas ce que vous voulez. Donc oui, cela dépend du cas d'utilisation. Mon montage a été de souligner la différence entre l'utilisation d'une simple timedelta et en passant par l'UTC. Vous avez deux méthodes ici. Utilisez celui qui vous convient le mieux.
    • j'ai édité la réponse de sorte qu'il est plus clair. J'espère que vous convient le mieux
    • J'ai remplacé l'ensemble du bloc ajouté et rédigé recommencer parce que 1) il contient des invalides invite Python syntaxe, 2) non-reproductible valeurs d'entrée (maintenant) et 3) vous ne décrivent un cas où fuseau horaire-savez-vs-UTC questions alors qu'il y a trop de sources existantes sur Internet à laquelle on pourrait se référer pour de grandes explications de l'ensemble du contexte et du problème plus cas. En fin de compte, OP seulement demandé comment créer un fuseau horaire-conscient objet datetime, donc un court de soupçon/lien est préféré au lieu d'avoir >60% de la réponse dédiée à un autre problème.
    • Le "Ce que chaque développeur doit savoir à propos de" temps en maintenant le lien redirige vers-le-vent de la page d'accueil, qui a été le même que celui-ci? blogs.windwardreports.com/davidt/2009/11/...
    • merci pour le heads-up! Depuis votre proposition d'article de blog que partiellement correspond au contenu, je l'ai remplacé avec une archive web lien.

    InformationsquelleAutor AndiDog
  2. 92

    Obtenir l'heure actuelle, dans un fuseau horaire:

    import datetime
import pytz
my_date = datetime.datetime.now(pytz.timezone('US/Pacific'))
    • Voir ceci.
    • vous ne devez PAS utiliser localisée temps, sauf pour la sortie. Beaucoup de choses vont de mal lors de l'utilisation de fuseau horaire en fonction datetime: un simple timedelta ne prend pas en compte l'heure d'été à moins que vous soyez dans l'heure UTC pour commencer. Toujours utiliser le fuseau horaire courant basé sur l'heure UTC. convertir au fuseau horaire local sur la sortie en cas de besoin.
    • Réitérer un désaccord avec @MrE que je l'ai déjà exprimé dans les commentaires sur le acceptées réponse: il y a des raisons parfaitement valides pour travailler avec localisées datetimes et "vous ne devez PAS utiliser localisée temps, sauf pour la sortie" est trop large et des conseils. Supposons que vous êtes l'ajout de 1 jour à un datetime quelques heures avant une heure avancée de limite à laquelle les horloges de revenir en arrière en une heure. Quel résultat voulez-vous? Si vous pensez que le temps devrait être la même, l'utilisation localisée datetimes. Si vous pensez qu'il doit être une heure plus tôt, l'utilisation fuseau horaire UTC ou naïfs datetimes. Ce qui fait sens selon le domaine.
    • autant que je peux accepter que vous souhaitez AJOUTER ou SOUSTRAIRE un nombre de jours ou d'heures et pas de soins sur le fuseau horaire de questions (comme ton exemple), ce commentaire se rapporte à passer le fuseau horaire en temps compensé à un client. Depuis le Python est principalement utilisé pour la sauvegarde de fin de processus, il passe des fois à un client. Le serveur doit toujours passer la date/l'heure en UTC et le client doit le convertir à sa propre date/heure/fuseau horaire, sinon, les mauvaises choses se produisent: il suffit de cocher la sortie de datetime.datetime(2016, 11, 5, 9, 43, 45, tzinfo=pytz.timezone('US/Pacific')) et voir si c'est ce que vous attendiez
    • en.wikipedia.org/wiki/Local_mean_time
    • "Le serveur doit toujours passer la date/l'heure en UTC et le client doit le convertir à sa propre date/heure/fuseau horaire" - non, ce n'est pas universellement vrai. Parfois, en utilisant le client de son fuseau horaire est inapproprié et le fuseau horaire doit être transmis en tant que partie des données. Si, comme un Londonien, j'ai vue de la réunion de San Francisco club d'échecs sur leur site, je devrais les voir à San Francisco le temps, pas le dans les, heure de Londres.
    • pour datetime.datetime(2016, 11, 5, 9, 43, 45, tzinfo=pytz.timezone('US/Pacific')), oui, c'est un horrible piège de Python datetime API. Pour quelqu'un demandais WTF est avec le résultat, la réponse est que la tzinfo argument de la datetime constructeur est tout simplement cassé pour pytz fuseaux horaires; vous devez utiliser les fuseaux horaires' .localize() méthode pour créer fuseau horaire-conscient datetimes à la place.)
    • "Si, comme un Londonien, j'ai vue de la réunion de San Francisco club d'échecs sur leur site, je devrais les voir à San Francisco le temps, pas le dans les, heure de Londres." Puis ne pas utiliser les fuseaux horaires, l'heure UTC ou quoi que ce soit, vous avez juste besoin naïf date de fois.

    InformationsquelleAutor philfreo
  3. 44

    En Python 3, de la bibliothèque standard, il est beaucoup plus facile de spécifier le fuseau horaire UTC comme:

    >>> import datetime
>>> datetime.datetime.now(datetime.timezone.utc)
datetime.datetime(2016, 8, 26, 14, 34, 34, 74823, tzinfo=datetime.timezone.utc)

    Si vous voulez une solution qui n'utilise que de la bibliothèque standard, et qui fonctionne dans les deux Python 2 et Python 3, voir J. F. Sébastien, en réponse.

    InformationsquelleAutor Flimm
  4. 17

    Voici un stdlib solution qui fonctionne sur Python 2 et 3:

    from datetime import datetime

now = datetime.now(utc) # timezone-aware datetime.utcnow()
today = datetime(now.year, now.month, now.day, tzinfo=utc) # midnight

    où today est conscient datetime instance représentant le début de la journée (minuit) à l'UTC et l' utc est un tzinfo objet (exemple à partir de la documentation):

    from datetime import tzinfo, timedelta

ZERO = timedelta(0)

class UTC(tzinfo):
    def utcoffset(self, dt):
        return ZERO

    def tzname(self, dt):
        return "UTC"

    def dst(self, dt):
        return ZERO

utc = UTC()

    Connexes: comparaison des performances de plusieurs façons d'obtenir de minuit (le début d'une journée pour une heure UTC.

    Remarque: il est plus complexe, à obtenez de minuit, pour un temps, d'une zone de non-correction d'un décalage utc.

    InformationsquelleAutor jfs
  5. 13

    Une autre méthode pour construire fuseau horaire conscient objet datetime représentant l'heure courante:

    import datetime
import pytz

pytz.utc.localize( datetime.datetime.utcnow() )
    • notez que pytz.utc et pytz.UTC sont tous les deux définis (et ce sont les mêmes)
    • Cette réponse, c'est mieux que les acceptée car elle est plus universelle: replace()ing fuseau horaire est généralement sujette à des erreurs dans la plupart des autres utilisations, tout en localize()ing est la voie privilégiée pour l'attribution de fuseau horaire pour naïve horodateurs.
    • méthode échoue ambiguës heure locale (non-utc entrée). @philfreo réponse qui utilise .now(pytz_timezone) continue à travailler dans de tels cas.
    • Comme spécifié dans python docs, .now(pytz_timezone) fait exactement la même chose que localize(utcnow) - d'abord il génère du courant de temps en temps UTC, puis il l'attribue à une timezone: "<...>Dans ce cas, le résultat est équivalent à tz.fromutc(datetime.utcnow().replace(tzinfo=tz))". Les deux réponses sont correctes, et le travail toujours.
    • Le seul naïf (non-utc) le temps qui peut être fait en toute sécurité fuseau horaire courant est maintenant : le système sous-jacent est censé connaître la valeur UTC et pytz par OLSON db est censé savoir comment le convertir à n'importe quel fuseau horaire du monde. Tout naïf (non-utc) heure du fuseau horaire la conscience est difficile à cause de l'ambiguïté au cours de l'heure d'été à des quarts de travail. Ce n'est pas un problème de .localize (nourrir un is_dst valeur qui fait que cela fonctionne pour n'importe quelle date). C'est un problème inhérent à l'heure d'été à la pratique.
    • Poser une autre question si tu ne comprends pas pourquoi .localize(now) échoue.
    • être plus précis
    • ou poser une autre question si vous ne comprenez pas pourquoi localize est mieux que replace pour les non-dates utc.
    • utilisation @.. si vous voulez de moi pour être informé de vos commentaires comme je le fais. Ce qui est faux: 1. pytz.utc.localize() est mieux que .replace(tzinfo=pytz.utc) -- mal 2. non_utc_tz.localize(utcnow) est mieux que .now(non_utc_tz) -- mal. Regardez votre first et 2nd commentaires.
    • Sebastian mal. localize ne s'agit pas ambigu timedates (non-utc entrée) - si vous lui donnez corriger is_dst paramètre. Regardez votre first commentaire. pytz.utc.localize(<naive_utc_date>) fait exactement la même chose que <naive_utc_date>.replace(tzinfo=pytz.utc) - ce n'est pas mon point. Si vous répétez une seule et même chose incorrecte millions de fois il l'habitude de devenir plus correct, juste à cause de cela.
    • Aussi, non_utc_tz.localize(utcnow) fait exactement la même chose que <naive_utc_date>.replace(tzinfo=pytz.utc). Je ne vois pas en doute.
    • Je vais vous rappeler: la quesiton est "timezone-conscient datetime.aujourd'hui()". Fait: datetime.now(tz) fonctionne sans préciser is_dst paramètre. Fait: .replace(tzinfo=pytz.utc) travaille pour le fuseau horaire UTC. Fait: tz.localize(now) peut échouer pour les non-utc fuseaux horaires. Vous pouvez lever l'ambiguïté en utilisant is_dst (pour certains fuseaux horaires, il ne fonctionne que dans les versions récentes), mais comment pouvez-vous savoir is_dst par programmation de toute façon? Conslusion: .now(tz) est une meilleure option que tz.localize(now, is_dst=is_dst) ici (vous pouvez utiliser .replace(tzinfo=pytz.utc) pour des raisons de performances si votre profiler le dit).
    • Sebastian: je vais vous le rappeler: je n'ai pas de proposer non_utc_tz.localize(non_utc_now, is_dst=is_dst). Qu'est ce que vous dites. Fait: votre conclusion n'a rien à voir avec ce que j'ai dit.
    • Permettez-moi de répéter mon point de vue: les Deux replace et localize peut être utilisé pour l'affectation d'un fuseau horaire à un naïf d'horodatage. Les deux fonctionnent de la même manière lorsque l'opération est sans ambiguïté. Mais si l'affectation est ambigu localize est mieux, car il va vous avertir à ce sujet par la levée d'une exception qui vous pouvez vous rattraper et puis exécutez de nouveau le bon is_dst valeur si vous le connaissez (vous pouvez demander à un utilisateur final par exemple) ou de la valeur arbitraire de vous donner 50:50 chance du droit suppose. Replace sur l'autre main vous donnera le même 50:50 de chances de la droite deviner, mais il l'habitude de vous informer à propos de l'ambiguïté.
    • Sinon, je suis d'accord avec tous les Faits. Et je trouve aussi datetime.now(pytz.utc) la meilleure façon de le faire.
    • Plz l'examen de mon réponse à cette question.
    • peut échouer pour n'importe quel fuseau horaire qui a un décalage utc dans le passé, même si le résultat est sans équivoque. Toujours utiliser .localize() au lieu de .replace() pour les fuseaux horaires avec un non-correction d'un décalage utc: Datetime Fuseau horaire de conversion à l'aide de pytz
    • Sebastian enfin, vous avez mes mon point de vue ("localiser()ing est la voie privilégiée pour l'attribution de fuseau horaire pour naïve horodateurs"). Ouais, je suis d'accord, vous avez eu tort depuis le début. Un an, c'est vraiment pas si longtemps pour ce formidable question 😉
    • Votre point de vue: ".now(pytz_timezone) fait exactement la même chose que de localiser(utcnow)" est toujours mal. Relisez mes commentaires attentivement ce moment.
    • Sebastian, vous ne pouvez pas admettre vous êtes dans l'erreur tout le temps? Calmez-vous, relisez mes commentaires attentivement et arrêtez de spammer moi.
    • vous ne pouvez pas fournir une seule déclaration de la part de mes commentaires que c'est faux. Si vous continuez à poster des déclarations inexactes; je pourrais continuer à les réfuter. On dirait qu'il est inutile dans ton cas, mais je pourrais continuer de le faire de sorte que vous ne seriez pas induits en erreur d'autres personnes.
    • Sebastian, Vous semblez comme à long terme des conversations. Je vais vous répondre en un an. Ils n'arriveront pas à lire une conversation de cette longue et inutile de toute façon. N'ai-je pas vous demander de cesser de spam - moi?

    InformationsquelleAutor Dariusz Walczak
  6. 9

    Si vous utilisez Django, vous pouvez définir les dates de non-tz courant (uniquement utc).

    Commentaire la ligne suivante dans settings.py:

    USE_TZ = True
    • où avez-vous vu django mentionnés dans cette question?
    • Maintenant, je veux juste ramper sous un rocher et mourir.
    • "non-tz conscience" n'a pas magiquement faire des dates seulement-UTC
    InformationsquelleAutor laffuste
  7. 6

    pytz est une bibliothèque Python qui permet la précision et de la croix-plate-forme de fuseau horaire calculs à l'aide de Python 2.3 ou supérieur.

    Avec la stdlib, ce n'est pas possible.

    Voir une question similaire sur DONC.

    InformationsquelleAutor user225312
  8. 6

    Ici est une façon de générer avec le stdlib:

    import time
from datetime import datetime

FORMAT='%Y-%m-%dT%H:%M:%S%z'
date=datetime.strptime(time.strftime(FORMAT, time.localtime()),FORMAT)

    date va stocker la date et l' décalage UTC, non pas de la date à le fuseau horaire UTC, de sorte que vous pouvez utiliser cette solution si vous avez besoin d'identifier qui fuseau horaire, la date est généré à. Dans cet exemple et dans mon fuseau horaire local:

    date
datetime.datetime(2017, 8, 1, 12, 15, 44, tzinfo=datetime.timezone(datetime.timedelta(0, 7200)))

date.tzname()
'UTC+02:00'

    La clé est l'ajout de la %z directive pour le FORMAT de représentation, pour indiquer le décalage UTC de temps générées struct. D'autres formats de représentation peuvent être consultés dans le module datetime docs

    Si vous avez besoin de la date à le fuseau horaire UTC, vous pouvez remplacer temps.localtime() avec temps.gmtime()

    date=datetime.strptime(time.strftime(FORMAT, time.gmtime()),FORMAT)

date    
datetime.datetime(2017, 8, 1, 10, 23, 51, tzinfo=datetime.timezone.utc)

date.tzname()
'UTC'

    Modifier

    Cela ne fonctionne que sur python3. Le z la directive n'est pas disponible sur python 2 _strptime.py code

    • ValueError: 'z' est une mauvaise directive dans le format '%Y-%m-%dT%H:%M:%S%z'
    • Vous êtes sur python 2, droit? Malheureusement, Il semble que le z la directive n'est pas disponible sur python 2. _strptime.py code
    InformationsquelleAutor jcazor
  9. 5

    Pourquoi ne pas utiliser dateutil comme décrit ici:
    http://joelinoff.com/blog/?p=802

    from dateutil.tz import tzlocal
# Get the current date/time with the timezone.
now = datetime.datetime.now(tzlocal())
    • Voir cette réponse par J. F. Sebastian pour une situation où ce qui donne un résultat incorrect.
    • Je pense que l'erreur dans l'autre post n'est pertinente que dans des cas d'utilisation spécifiques. Le tzlocal() fonction est toujours l'une des solutions les plus simples et devrait certainement être mentionné ici.
    InformationsquelleAutor G. Führ
  10. 2

    Vous pouvez créer un local timezone à l'aide de datetime par l'analyse de la sortie d'un time.strftime appel qui utilise le %z directive (introduit en Python 3.3), comme illustré par jcazor. Vous pouvez l'utiliser timezone pour créer un courant datetime exemple avec un one-liner:

    import time
from datetime import datetime

aware_local_now = datetime.now(
    tz=datetime.strptime(time.strftime("%z", time.localtime()), "%z").tzinfo)

print(aware_local_now)
2018-03-01 13:41:26.753644-08:00
    InformationsquelleAutor Mihai Capotă
  11. 1

    L'obtention d'un fuseau horaire-connaissance de la date de utc fuseau horaire est assez pour la date de soustraction de travail.

    Mais si vous voulez un fuseau horaire-connaissance de la date dans votre fuseau horaire, tzlocal est le chemin à parcourir:

    from tzlocal import get_localzone  # pip install tzlocal
from datetime import datetime
datetime.now(get_localzone())

    PS dateutil a une fonction similaire (dateutil.tz.tzlocal). Mais en dépit de partage le nom, il est totalement différent de la base de code, qui, comme a noté par J. F. Sebastian peut donner de mauvais résultats.

    • python est généralement utilisé sur le serveur. Fuseau horaire Local sur un serveur est généralement inutile et doit toujours être réglée sur UTC. Réglage datetime tzinfo de cette façon échoue dans certains cas. mieux utiliser UTC, puis localiser le voulait fuseau horaire uniquement sur la production. tout timedelta calcul pour l'exemple ne tient pas compte de l'heure d'été, donc ils doivent être faits en UTC, puis localisée.
    • Mal, futiles, des exemples?
    • essayez d'utiliser un objet datetime localisée dans un fuseau horaire qui observe l'heure d'été, d'ajouter un certain nombre de jours pour changer d'heure d'etat, et vous verrez que l'exploitation sur les objets datetime localisée au fuseau horaire d'échec et de ne pas respecter l'heure d'été. D'où mon commentaire que vous devriez TOUJOURS faire tout datetime fonctionnement en heure UTC.
    • le point de l'être: à ne pas faire, faire vos opérations en UTC, puis utiliser datetime.astimezone(fuseau horaire) pour convertir à l'localtime de la zone de sortie.
    InformationsquelleAutor Antony Hatchkins
  12. 0

    Si vous obtenez l'heure et la date actuelles en python puis importer la date et l'heure,pytz paquet python après, vous obtiendrez date et l'heure actuelles comme..

    from datetime import datetime
import pytz
import time
str(datetime.strftime(datetime.now(pytz.utc),"%Y-%m-%d %H:%M:%S%t"))
    InformationsquelleAutor jigar vagadiya
  13. 0

    Utiliser le fuseau horaire comme indiqué ci-dessous pour le fuseau horaire courant de date, par défaut est UTC:

        from django.utils import timezone
    today = timezone.now()
    InformationsquelleAutor Anupama V Iyengar
  14. 0

    Je suis en ajoutant que cette réponse est quelqu'un qui travaille fréquemment avec des non-UTC fuseaux horaires.

    Le seul fuseau horaire qui a sa propre méthode est timezone.utc, mais vous pouvez fudge un fuseau horaire avec tout décalage UTC si vous avez besoin d'aide de timedelta & timezone, et de les forcer à l'aide de .replace.

    In [1]: from datetime import datetime, timezone, timedelta

In [2]: def force_timezone(dt, utc_offset=0):
   ...:     return dt.replace(tzinfo=timezone(timedelta(hours=utc_offset)))
   ...:

In [3]: dt = datetime(2011,8,15,8,15,12,0)

In [4]: str(dt)
Out[4]: '2011-08-15 08:15:12'

In [5]: str(force_timezone(dt, -8))
Out[5]: '2011-08-15 08:15:12-08:00'

    À l'aide de timezone(timedelta(hours=n)) que la zone est la vraie balle d'argent ici, et il a beaucoup d'autres applications utiles.

    InformationsquelleAutor tmck-code
  15. -1

    Une autre alternative, dans mon esprit, mieux, à l'aide de Pendulum au lieu de pytz. Considérons le code simple suivant:

    >>> import pendulum

>>> dt = pendulum.now().to_iso8601_string()
>>> print (dt)
2018-03-27T13:59:49+03:00
>>>

    Pour installer Pendule et de voir leur documentation, rendez-vous ici. Il ont des tonnes d'options (comme la simple ISO8601, RFC3339 et beaucoup d'autres le support du format), de meilleures performances et une tendance à céder plus simple de code.

    • je ne sais pas pourquoi le vote ici-bas, ce code est en travaillant dans plusieurs programmes qui s'exécutent 7/24 pour moi :). non pas que j'ai l'esprit d'autres avis, mais merci de dire pourquoi il ne fonctionne pas pour vous, afin de me permettre de le vérifier. Merci d'avance
    InformationsquelleAutor ng10