Convertir UTC datetime chaîne locale datetime

Je n'ai jamais eu de convertir l'heure et de l'heure UTC. Récemment eu une demande pour avoir mon appli soit le fuseau horaire courant, et je l'ai eu à me courir en rond. Beaucoup d'informations sur la conversion de l'heure locale à l'UTC, que j'ai trouvé assez élémentaire (peut-être que je fais de mal que de bien), mais je ne peux pas trouver toutes les informations sur facilement la conversion de l'heure UTC pour les utilisateurs finaux dans le fuseau horaire.

En un mot, et l'application android envoie moi (appengine app) et des données dans les données est un timestamp. Pour stocker le timestamp de l'heure utc, je suis en utilisant:

datetime.utcfromtimestamp(timestamp)

Qui semble être au travail. Lorsque mon application stocke les données, c'est le magasin que 5 heures d'avance (je suis HNE -5)

Les données sont stockées sur appengine de BigTable, et quand récupéré il sort comme une chaîne de caractères comme suit:

"2011-01-21 02:37:21"

Comment puis-je convertir cette chaîne DateTime dans le fuseau horaire correct?

Aussi, qu'est-ce que le stockage recommandée pour les utilisateurs d'informations de fuseau horaire? (Comment faites-vous généralement store tz info c'est à dire: "-5:00" ou "EST", etc, etc ?) Je suis sûr que la réponse à ma première question, peut contenir un paramètre les réponses à la seconde.

connexes: Comment faire pour convertir un python utc datetime pour un datetime local en utilisant uniquement de la bibliothèque standard de python?
Cette réponse montre comment résoudre ce problème d'une manière simple.

InformationsquelleAutor MattoTodd | 2011-01-22

345

Si vous ne voulez pas vous fournir votre propre tzinfo objets, découvrez la python-dateutil de la bibliothèque. Il fournit tzinfo implémentations sur le haut d'une zoneinfo (Olson) de la base de données de telle sorte que vous pouvez vous référer aux règles de fuseau horaire par un peu de nom canonique.
```
from datetime import datetime
from dateutil import tz

# METHOD 1: Hardcode zones:
from_zone = tz.gettz('UTC')
to_zone = tz.gettz('America/New_York')

# METHOD 2: Auto-detect zones:
from_zone = tz.tzutc()
to_zone = tz.tzlocal()

# utc = datetime.utcnow()
utc = datetime.strptime('2011-01-21 02:37:21', '%Y-%m-%d %H:%M:%S')

# Tell the datetime object that it's in UTC time zone since 
# datetime objects are 'naive' by default
utc = utc.replace(tzinfo=from_zone)

# Convert time zone
central = utc.astimezone(to_zone)
```
Modifier Élargi exemple pour montrer strptime utilisation

Edit 2 Fixe d'utilisation de l'API de montrer meilleur point d'entrée de la méthode

Modifier 3 Inclus auto-détection des méthodes pour les fuseaux horaires (Yarin)
- Merci pour cette remarque. La bibliothèque des points à ce projet (twinsun.com/tz/tz-link.htm) comme source pour les fuseaux horaires. Savez-vous où il y a une liste des possibilités de chaîne que vous pouvez passer à gettz() ?
- en.wikipedia.org/wiki/List_of_tz_database_time_zones
- Aussi, il y a une autre bibliothèque appelée pytz (pytz.sourceforge.net) qui fournit la tz de la base de données ainsi. Personnellement, je préfère python-dateutil raison de tous les autres modules d'utilitaire, il offre, mais si vous ne voyez pas vous-même à l'aide de ces modules pytz travaille trop.
- Il ressemble à python-dateutil fonctionnent très bien. Excellente Solution.
- essayé ton code mais ce n'est pas vraiment de travail, from_zone et to_zone sont NoneTypes donc utc.aztimezone(to_zone), qui je pense devrait être "astimezone" revient " TypeError: astimezone() argument 1 doit être de type datetime.tzinfo, pas None'
- Si from_zone et to_zone sont None, alors il y a peut être un problème avec le zoneinfo base de données sur votre système. Quel système d'exploitation/distribution utilisez-vous? Merci pour la faute de frappe, j'ai corrigé.
- Je suis de la même None erreur comme @aschmid00, trop. Je suis sur la dernière 10.6.7 version de Snow Leopard. Est il possible que je peux vérifier pour voir qui tz sont dans mon zoneinfo base de données?
- Sur mon précédent commentaire, j'ai été en mesure d'importer dateutil.tz et l'utilisation tz.tzutc() et tz.tzlocal() que le fuseau horaire objets que je cherchais. Il ressemble à la fois de la zone de la base de données sur mon système est bon (j'ai vérifié dans /usr/share/zoneinfo). Pas sûr de ce qui était en haut.
- Vous êtes sur la bonne voie. Le tz module est le bon point d'entrée à l'aide de cette bibliothèque. J'ai mis à jour ma réponse pour refléter cela. Le dateutil.zoneinfo module j'exposais précédemment est utilisée en interne par le tz module comme une chute en arrière si elle ne peut pas localiser le système de zoneinfo DB. Si vous regardez à l'intérieur de la bibliothèque, vous verrez qu'il y a un zoneinfo DB archive dans le paquet qu'il utilise si il ne peut pas trouver de votre système DB. Mon ancien exemple a été d'essayer de frapper le DB directement et je devine que vous avez eu des problèmes de chargement du privé DB (n'est pas sur le python path en quelque sorte?)
- href="https://github.com/dateutil/dateutil/issues/112" >utc -> local de conversion est cassée dans dateutil, utilisez pytz à la place.
- c'est corrigé dans la #225
- le github question est fermée, mais je ne sais pas si l'origine du test de #112 passes. Avez-vous essayé avec la mise à jour dateutil version?
- Hmm, j'ai juste regardé le dernier commentaire dans #112 disant qu'il a été fixé, toutes mes excuses si c'était prématuré. Permettez-moi de test.
- Je suis correct tz données pour la PDT dès maintenant
- vous êtes de droite. test passe sur dateutil de la branche master. Si le changement n'est pas encore sorti (le test échoue sur la version actuelle: python-dateutil-2.5.2).
- Est-il un problème avec simplement l'ajout d'un montant fixe de temps à autre temps à un autre fuseau horaire
- Il dépend de la sophistication de votre application doit être, mais en général, les applications, oui, c'est un problème. Tout d'abord en fonction de ce moment de l'année, le nombre d'heures à ajouter/soustraire pourrait changer car certains fuseaux horaires de l'honneur de l'heure d'été et d'autres ne le font pas. Deuxièmement, les règles de fuseau horaire sont arbitrairement changé au fil du temps, donc si vous travaillez avec un passé de date/heure, vous devez appliquer les règles qui étaient en vigueur à ce point dans le temps, pas le temps présent. C'est pourquoi il est préférable d'utiliser une API qui permet d'exploiter les Olson TZ base de données derrière les coulisses.
- Donc, ne tient pas compte de l'heure d'été ou pas? Je suis un peu confus. Je suis de l'EST (généralement GMT-5), mais avec l'heure d'été c'est actuellement GMT-4. Si j'ai une date dans le passé qui est GMT-5, mais d'une autre date est aujourd'hui (qui est GMT-4), je suppose que cette réponse ne sera pas le prendre en compte et de l'utilisation GMT-4 pour les deux dates, à droite? Y aurait-il une solution simple pour que, depuis l'heure d'été n'a pas de début ou de fin à la même date chaque année?
- Oui, si vous êtes correctement à l'aide de l'UTC au lieu d'un localisée datetime. UTC est agnostique à l'heure d'été donc un UTC datetime ne change pas lorsque l'heure d'été règles de changement dans un fuseau horaire particulier. C'est un pur "dans le temps". C'est quand vous "localiser" de l'UTC à un moment particulier de la zone que vous devez être conscient des règles d'heure d'été et ces règles sont encodées dans la base de données tz les différentes bibliothèques de l'utiliser. La tz de la base de données est mise à jour en tant que facteurs géopolitiques affecter l'heure d'été. Il s'ensuit qu'il est important de garder votre tz base de données à jour (mise à jour régulière des bibliothèques, des paquets du système, etc).
- Donc, si j'ai un rapport à l'heure UTC en février et une autre en juillet et que j'applique la tz.tzlocal() à tous les deux, tout est smart assez pour le faire fonctionner? Vous dites UTC ne change pas avec l'heure d'été, donc si il y a disons exactement 6 mois (environ 4320h) entre les 2 dates, quand j'applique la tz.tzlocal() il y aura toujours des 4320h entre les deux dates, même si je visais heure par heure, il pourrait être 4321 parce que nous avons sauté d'une heure pour l'heure d'été? Si cela fonctionne de cette façon, c'est la date de juillet est probablement faux (GMT-5 au lieu de GMT-4 avec l'heure d'été). Désolé si c'est confus, juste essayer de comprendre ici.
- Je veux dire, nous avons littéralement passer une heure en Mars et le faire revenir en novembre IIRC avec l'heure d'été. Il doit être quelque part.
- Yep, je comprends combien d'heure d'été fonctionne. Votre problème est que vous êtes en train de penser à l'heure locale, pas de l'UTC. Vous devez penser à l'heure UTC et l'affichage de vos temps zone localisée de temps en découlent (basé sur le tz règles qui sont/étaient en effet à l'heure UTC). Vous pouvez aller de l'UTC à localisées moment et sans ambiguïté, mais vous ne pouvez pas toujours aller d'un point localisé temps à l'UTC, sans ambiguïté. Lorsque l'heure d'été "retombe" une heure, vous avez une heure entière au long de la fenêtre de temps qui se répète dans le temps local, mais pas en UTC. En UTC, l'avant-seul aspect du temps est préservée. C'est pourquoi la recommandation...
- Est généralement pour stocker les horodatages UTC à tout moment vous avez besoin de convertir entre les fuseaux horaires (ou tout simplement le faire exclusivement). Dans certaines situations, vous pouvez également besoin de savoir quel fuseau horaire d'un morceau de données a été capturé, afin de stocker le fuseau horaire ou le localisées temps à côté d'elle, mais ayant l'horodatage UTC vous assure d'avoir un "point à temps" qui n'est pas ambiguë à l'égard de la localité.
- Armin fait un bon travail en expliquant les choses dans ce billet de blog: lucumr.pocoo.org/2011/7/15/eppur-si-muove
InformationsquelleAutor Joe Holloway
36

Voici un élastique méthode qui ne dépend pas de toutes les bibliothèques externes:
```
from datetime import datetime
import time

def datetime_from_utc_to_local(utc_datetime):
    now_timestamp = time.time()
    offset = datetime.fromtimestamp(now_timestamp) - datetime.utcfromtimestamp(now_timestamp)
    return utc_datetime + offset
```
Cela évite les problèmes de synchronisation de DelboyJay l'exemple. Et le moindre des problèmes de timing dans Erik van Oosten de l'amendement.

À une intéressante note de bas de page, le décalage horaire est calculée ci-dessus peut différer de la suite apparemment l'équivalent de l'expression, probablement en raison de l'heure avancée des changements à la règle:
```
offset = datetime.fromtimestamp(0) - datetime.utcfromtimestamp(0) # NO!
```
Mise à jour: Cet extrait a la faiblesse de l'aide de l'UTC décalage de l'heure présente, qui peut différer de l'UTC offset de l'entrée de type datetime. Voir les commentaires sur cette réponse pour une autre solution.

Pour contourner les différents temps, prenez le époque de l'heure passée. Voici ce que je fais:
```
def utc2local (utc):
    epoch = time.mktime(utc.timetuple())
    offset = datetime.fromtimestamp (epoch) - datetime.utcfromtimestamp (epoch)
    return utc + offset
```
- Cela fonctionne bien et ne nécessite rien d'autre que du temps et datetime.
- mais c'est incorrect. Il ne supporte pas l'heure d'été ou des fuseaux horaires différents décalage utc dans le passé pour d'autres raisons. Support complet sans pytz-comme db est impossible, voir PEP-431. Si vous pouvez écrire stdlib seule solution qui fonctionne dans de tels cas, sur les systèmes qui ont déjà historique fuseau horaire db par exemple, Linux, OS X, reportez-vous à ma réponse.
- Tu dis que ce code ne fonctionne pas en général, mais aussi dire qu'il fonctionne sur OS X et Linux. Entendez-vous ce code ne fonctionne pas sur Windows?
- votre code peut échouer sur Linux et OS X aussi. La différence entre la vôtre et mine stdlib des solutions, c'est que la vôtre utilise courant décalage qui peut être différente de décalage utc à utc_datetime temps.
- Bon appel. C'est une différence subtile. Le décalage UTC peuvent changer au fil du temps. soupir
InformationsquelleAutor David Foster
21

Voir le datetime documentation sur tzinfo objets. Vous avez à mettre en œuvre les fuseaux horaires que vous souhaitez pour vous soutenir. Les exemples en bas de la documentation.

Voici un exemple simple:
```
from datetime import datetime,tzinfo,timedelta

class Zone(tzinfo):
    def __init__(self,offset,isdst,name):
        self.offset = offset
        self.isdst = isdst
        self.name = name
    def utcoffset(self, dt):
        return timedelta(hours=self.offset) + self.dst(dt)
    def dst(self, dt):
            return timedelta(hours=1) if self.isdst else timedelta(0)
    def tzname(self,dt):
         return self.name

GMT = Zone(0,False,'GMT')
EST = Zone(-5,False,'EST')

print datetime.utcnow().strftime('%m/%d/%Y %H:%M:%S %Z')
print datetime.now(GMT).strftime('%m/%d/%Y %H:%M:%S %Z')
print datetime.now(EST).strftime('%m/%d/%Y %H:%M:%S %Z')

t = datetime.strptime('2011-01-21 02:37:21','%Y-%m-%d %H:%M:%S')
t = t.replace(tzinfo=GMT)
print t
print t.astimezone(EST)
```
De sortie
```
01/22/2011 21:52:09 
01/22/2011 21:52:09 GMT
01/22/2011 16:52:09 EST
2011-01-21 02:37:21+00:00
2011-01-20 21:37:21-05:00a
```
- Merci pour l'accepter! J'ai mis à jour légèrement pour traduire votre exemple spécifique de temps. L'analyse du temps de crée ce que les médecins appellent un "naïf" du temps. Utilisation replace de régler le fuseau horaire de GMT et de faire le fuseau horaire "conscients", puis utiliser astimezone convertir à un autre fuseau horaire.
- J'ai remarqué que le modifier. Merci de prendre le temps!!
- Désolé pour les échange pour la réponse de Joe. Techniquement votre réponse explique exactement comment le faire avec raw python (ce qui est bon à savoir), mais la bibliothèque, il a proposé de me prend pour une solution beaucoup plus rapide.
- Ne regarde pas comme il gère automatiquement l'heure d'été.
- il n'était pas destiné à. Les règles sont complexes et changent souvent.
InformationsquelleAutor Mark Tolonen

Si vous voulez obtenir le résultat correct, même pour l'époque qui correspond à un ambiguë, heure locale (par exemple, lors d'une transition d'heure d'été) et/ou le décalage utc différents à des moments différents dans votre fuseau horaire local puis utilisez pytz de fuseaux horaires:

#!/usr/bin/env python
from datetime import datetime
import pytz    # $ pip install pytz
import tzlocal # $ pip install tzlocal

local_timezone = tzlocal.get_localzone() # get pytz tzinfo
utc_time = datetime.strptime("2011-01-21 02:37:21", "%Y-%m-%d %H:%M:%S")
local_time = utc_time.replace(tzinfo=pytz.utc).astimezone(local_timezone)

InformationsquelleAutor jfs

7

Cette réponse devrait être utile si vous ne souhaitez pas utiliser d'autres modules d'ailleurs datetime.

datetime.utcfromtimestamp(timestamp) retourne un naïf datetime objet (pas au courant). Conscients sont fuseau horaire courant, et naïf ne le sont pas. Vous voulez une connaissance si vous le voulez convertir entre les fuseaux horaires (par exemple, entre l'heure UTC et l'heure locale).

Si vous n'êtes pas l'un de l'instanciation de la date pour commencer, mais vous pouvez toujours créer un naïf datetime objet en heure UTC, vous pourriez veux essayer ce Python 3.x code pour convertir:
```
import datetime

d=datetime.datetime.strptime("2011-01-21 02:37:21", "%Y-%m-%d %H:%M:%S") #Get your naive datetime object
d=d.replace(tzinfo=datetime.timezone.utc) #Convert it to an aware datetime object in UTC time.
d=d.astimezone() #Convert it to your local timezone (still aware)
print(d.strftime("%d %b %Y (%I:%M:%S:%f %p) %Z")) #Print it with a directive of choice
```
Être prudent de ne pas conclure à tort que si votre fuseau horaire est actuellement MDT que l'heure d'été ne fonctionne pas avec le code ci-dessus puisqu'il imprime MST. Vous remarquerez que si vous modifiez le mois d'août, il va imprimer MDT.

Un autre moyen facile d'obtenir un courant datetime objet (également en Python 3.x) est de créer avec un fuseau horaire spécifié pour commencer. Voici un exemple, à l'aide de l'UTC:
```
import datetime, sys

aware_utc_dt_obj=datetime.datetime.now(datetime.timezone.utc) #create an aware datetime object
dt_obj_local=aware_utc_dt_obj.astimezone() #convert it to local time

#The following section is just code for a directive I made that I liked.
if sys.platform=="win32":
    directive="%#d %b %Y (%#I:%M:%S:%f %p) %Z"
else:
    directive="%-d %b %Y (%-I:%M:%S:%f %p) %Z"

print(dt_obj_local.strftime(directive))
```
Si vous utilisez Python 2.x, vous aurez probablement à sous-classe datetime.tzinfo et l'utiliser pour vous aider à créer une conscience datetime objet, depuis datetime.timezone n'existe pas en Python 2.x.

InformationsquelleAutor Shule

Si l'aide de django, vous pouvez utiliser le fuseau horaire.localtime méthode (voir https://docs.djangoproject.com/en/dev/topics/i18n/timezones/).

from django.utils import timezone
date 
# datetime.datetime(2014, 8, 1, 20, 15, 0, 513000, tzinfo=<UTC>)

timezone.localtime(date)
# datetime.datetime(2014, 8, 1, 16, 15, 0, 513000, tzinfo=<DstTzInfo 'America/New_York' EDT-1 day, 20:00:00 DST>)

InformationsquelleAutor frmdstryr

1

J'traditionnellement reporter à l'interface -- send fois depuis le backend des timestamps ou de quelque autre format datetime au format UTC, puis de laisser le client à comprendre le décalage horaire et de rendre ces données dans le bon fuseau horaire.

Pour une webapp, c'est assez facile à faire en javascript -- vous pouvez comprendre le navigateur du décalage horaire assez facilement à l'aide de builtin méthodes et de rendre les données depuis le backend correctement.
- Cela fonctionne bien dans beaucoup de cas où vous êtes tout simplement la localisation pour l'affichage. Parfois, cependant, vous aurez besoin pour effectuer une logique d'entreprise basée sur le temps de l'utilisateur de la zone et vous aurez envie d'être capable de faire la conversion de la couche serveur d'applications.
InformationsquelleAutor Matt Billenstein
1

Ici est un moyen rapide et sale version qui utilise les systèmes locaux des paramètres de travailler sur la différence de temps. REMARQUE: Ceci ne fonctionnera pas si vous avez besoin de les convertir à un fuseau horaire que votre système actuel n'est pas en cours d'exécution. J'ai testé ce avec le royaume-UNI paramètres sous BST fuseau horaire
```
from datetime import datetime
def ConvertP4DateTimeToLocal(timestampValue):
   assert isinstance(timestampValue, int)

   # get the UTC time from the timestamp integer value.
   d = datetime.utcfromtimestamp( timestampValue )

   # calculate time difference from utcnow and the local system time reported by OS
   offset = datetime.now() - datetime.utcnow()

   # Add offset to UTC time and return it
   return d + offset
```
- il devrait être datetime.fromtimestamp(ts): posix timestamp (float secondes) -> objet datetime en heure locale (il fonctionne bien si l'OS se souvient passé décalages horaires pour le fuseau horaire local c'est à dire, sur Unix, mais pas sur Windows pour les dates dans le passé)). Sinon pytz pourrait être utilisé.
- Puis-je suggérer de faire ce qui suit: offset = datetime.utcnow().replace(minute=0, second=0, microsecond=0) - datetime.now().replace(minute=0, second=0, microsecond=0) je suis bizarre différences microseconde sans elle.
- avez-vous essayé datetime.fromtimestamp(ts) au lieu de la réponse?
InformationsquelleAutor DelboyJay
1

Vous pouvez utiliser calendar.timegm pour convertir votre temps de secondes depuis l'époque Unix et time.localtime de se reconvertir:
```
import calendar
import time

time_tuple = time.strptime("2011-01-21 02:37:21", "%Y-%m-%d %H:%M:%S")
t = calendar.timegm(time_tuple)

print time.ctime(t)
```
Donne Fri Jan 21 05:37:21 2011 (parce que je suis à l'UTC+03:00 fuseau horaire).

InformationsquelleAutor myaut

De la réponse ici, vous pouvez utiliser le module pour convertir de l'utc à l'heure locale définie dans votre ordinateur:

utc_time = time.strptime("2018-12-13T10:32:00.000", "%Y-%m-%dT%H:%M:%S.%f")
utc_seconds = calendar.timegm(utc_time)
local_time = time.localtime(utc_seconds)

InformationsquelleAutor franksands

Vous pouvez utiliser flèche

from datetime import datetime
import arrow

now = datetime.utcnow()

print(arrow.get(now).to('local').format())
# '2018-04-04 15:59:24+02:00'

vous pouvez nourrir arrow.get() avec quoi que ce soit. timestamp, iso chaîne de caractères etc

InformationsquelleAutor d21d3q

import datetime

def utc_str_to_local_str(utc_str: str, utc_format: str, local_format: str):
    """
    :param utc_str: UTC time string
    :param utc_format: format of UTC time string
    :param local_format: format of local time string
    :return: local time string
    """
    temp1 = datetime.datetime.strptime(utc_str, utc_format)
    temp2 = temp1.replace(tzinfo=datetime.timezone.utc)
    local_time = temp2.astimezone()
    return local_time.strftime(local_format)

utc = '2018-10-17T00:00:00.111Z'
utc_fmt = '%Y-%m-%dT%H:%M:%S.%fZ'
local_fmt = '%Y-%m-%dT%H:%M:%S+08:00'
local_string = utc_str_to_local_str(utc, utc_fmt, local_fmt)
print(local_string)   # 2018-10-17T08:00:00+08:00

par exemple, mon fuseau horaire est " +08:00'. entrée utc = 2018-10-17T00:00:00.111 Z, alors j'aurai de sortie = 2018-10-17T08:00:00+08:00

Vous devriez donner une meilleure description de votre problème en texte brut, où vous expliquez le reste des utilisateurs-ce que vous essayez d'atteindre, et qui est de votre problème

InformationsquelleAutor Eureka Bing

Vous devez vous connecter pour publier un commentaire.

De sortie