Hi James, I'm just forwarding the issue to python-tz maintainers - may be they will be able to clarify it.
Thanks for the hint Andreas. On Tue, Mar 28, 2017 at 12:05:22PM +0100, James Cowgill wrote: > > 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 > -- http://fam-tille.de