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
