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
