timezone offset is not correct on version 2017.2

Bug #1678858 reported by Takumi Nakada on 2017-04-03
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
pytz
Undecided
Unassigned

Bug Description

Japanese Standard Time is 9 hours ahead of UTC.
However if I enter the following code, this appears.

>>> pytz.__version__
'2017.2'
>>> pytz.timezone('Asia/Tokyo')
<DstTzInfo 'Asia/Tokyo' LMT+9:19:00 STD>

Japan has not any Summer time, so that it must be +9:00:00 in years.
Here is the link. => https://www.timeanddate.com/time/zones/jst

And unless in Japan, that's incorrect all over the world, I think.
For examples, In U.S, there are already DST in many region. However it seems to be no effect to pytz library.

>>> pytz.timezone('US/Hawaii')
<DstTzInfo 'US/Hawaii' LMT-1 day, 13:29:00 STD>
(Hawaii does not have daylight saving time. It seems to be HAST.)

>>> pytz.timezone('US/Pacific')
<DstTzInfo 'US/Pacific' LMT-1 day, 16:07:00 STD>

https://www.timeanddate.com/time/zones/hadt
https://www.timeanddate.com/time/zones/pdt

I don't know what causes this problems because I've not read pytz source codes, but the above timezones having minutes like 19, 29 or 7 are not correct as timezones.

summary: - timezone offset is not correct
+ timezone offset is not correct on version 2017.2
description: updated
Simin Jie (simin-jie) wrote :

I also want to know why. The [Localized times and date arithmetic](http://pytz.sourceforge.net/#localized-times-and-date-arithmetic) only says the method to solve this but without reasons.

Barry Warsaw (barry) wrote :

We ran into this too, and it's a change from 2016.10:

(pytz) % pip install --quiet pytz
(pytz) % python -c "import pytz; print(repr(pytz.timezone('Asia/Tokyo')))"
<DstTzInfo 'Asia/Tokyo' LMT+9:19:00 STD>
(pytz) % pip uninstall --quiet --yes pytz
(pytz) % pip install --quiet pytz==2016.10
(pytz) % python -c "import pytz; print(repr(pytz.timezone('Asia/Tokyo')))"
<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>

Stuart Bishop (stub) wrote :

pytz.timezone('Asia/Tokyo') is the timezone definition for Tokyo at an arbitrary point in history. It happens to be the first one in the IANA database, which usually dates from before 1900 and often has a fractional hour as the offset making these bugs easy to spot. I don't think there were any relevant code changes changing the arbitrary zoneinfo that timezone('Asia/Tokyo') returns, so suspect the definition in the database changed; probably historic information being added. 'LMT' is used for Local Mean Time, where noon is when the sun is at its highest point over the civic centre and mostly hasn't been used since telegraph and railroad networks were built. In this case, for times pre 1888

The documented mechanisms for creating localized timezones, such as timezone('Asia/Tokyo').localize(datetime(2002, 10, 27, 6, 0, 0)) are needed so that the correct tzinfo is used for that particular location and point in time. pytz.timezone('Asia/Tokyo') alone has just the location, and could represent one of dozens of correct tzinfos for the various historical and future points in time. It would have been nice for datetime(..., tzinfo=timezone(...)) to work, but it has always been impossible until the very latest versions of Python3.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers