La dernière version (version 2017.2) de la bibliothèque liée au fuseau horaire python gérée par Stuart Bishop a un comportement étrange, je vais donc la partager. http://pythonhosted.org/pytz/#localized-times-and-date-arithmetic
In [1]: import pytz
In [2]: pytz.__version__
Out[2]: '2016.10'
In [3]: pytz.timezone('Asia/Tokyo')
Out[3]: <DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>
In [1]: import pytz
In [2]: pytz.__version__
Out[2]: '2017.2'
In [3]: pytz.timezone('Asia/Tokyo')
Out[3]: <DstTzInfo 'Asia/Tokyo' LMT+9:19:00 STD>
Il y a une possibilité de bug car je n'ai trouvé aucun commentaire de l'auteur.
Pour cette raison, si vous convertissez UTC-> JST en lisant dans DB, il peut être désactivé de 19 minutes. C'est bogué parce qu'il y a des processus qui changent simplement et ne changent pas. Le traitement qui change et le traitement qui ne change pas sont résumés ci-dessous.
In [8]: tz = pytz.timezone('Asia/Tokyo')
In [10]: tz.localize(datetime.datetime.now())
Out[10]: datetime.datetime(2017, 4, 5, 9, 24, 56, 215625, tzinfo=<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>)
In [11]: datetime.datetime.now(tz=pytz.utc).astimezone(tz)
Out[11]: datetime.datetime(2017, 4, 5, 18, 27, 33, 912014, tzinfo=<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>)
In [9]: datetime.datetime.now().replace(tzinfo=tz)
Out[9]: datetime.datetime(2017, 4, 5, 9, 24, 45, 694185, tzinfo=<DstTzInfo 'Asia/Tokyo' LMT+9:19:00 STD>)
Quand je l'ai essayé, JST est correctement affecté dans un traitement non destructif tel que tz.localize, datetime.astimezone (tz). On sait que JST ne fonctionne pas lors de l'utilisation du code qui attribue de force le fuseau horaire avec datetime.replace (tz), et il se décale de 19 minutes.
Recommended Posts