The latest version (version 2017.2) of the python timezone-related library managed by Stuart Bishop has strange behavior, so I will share it. 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>
I couldn't find any comments from the author, so there is a possibility of a bug.
Due to this, if UTC-> JST is converted by reading from DB, it may be off by 19 minutes. It's buggy because there are some processes that just shift and don't shift. The processing that shifts and the processing that does not shift are summarized below.
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>)
When I tried it at hand, JST is properly assigned in non-destructive processing such as tz.localize, datetime.astimezone (tz). It is known that JST does not work and it shifts by 19 minutes when using the code that forcibly assigns timezone with datetime.replace (tz).
Recommended Posts