Hi, On 28/03/17 10:37, Andreas Tille wrote: > tags 858260 help > thanks > > Hi, > > I admit that when reading the bug report I have no idea how to fix it. > I can confirm that I can reproduce the issue in a recent unstable > chroot. I have added maintainers of tzdata, Debian Science and Debian > mentors in CC - just hoping for any helpful hint.
Whatever has happened, tzdata 2017a triggered it. tzdata 2016j-2: > $ python3 -c "import datetime, pytz; print(repr(datetime.datetime(2011, 1, 1, > tzinfo = pytz.timezone('Asia/Tokyo'))))" > datetime.datetime(2011, 1, 1, 0, 0, tzinfo=<DstTzInfo 'Asia/Tokyo' > JST+9:00:00 STD>) tzdata 2017a-1: > $ python3 -c "import datetime, pytz; print(repr(datetime.datetime(2011, 1, 1, > tzinfo = pytz.timezone('Asia/Tokyo'))))" > datetime.datetime(2011, 1, 1, 0, 0, tzinfo=<DstTzInfo 'Asia/Tokyo' > LMT+9:19:00 STD>) There was a Asia/Tokyo change in tzdata 2017a, but I don't really know how it caused this: @@ -1462,8 +1452,6 @@ # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Tokyo 9:18:59 - LMT 1887 Dec 31 15:00u - 9:00 - JST 1896 Jan 1 - 9:00 - JCST 1937 Oct 1 9:00 Japan J%sT # Since 1938, all Japanese possessions have been like Asia/Tokyo. Maybe it's a bug in python-tz? James
signature.asc
Description: OpenPGP digital signature