Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
At second thought it might not be a bug in python-tz, but some
undefined behavior that results from the pandas use of tz._utcoffset:
> tz = pytz.timezone('Asia/Tokyo')
> dt = datetime.datetime(2011,1,1)
>
> In[76]: tz.utcoffset(dt)
> Out[76]: datetime.timedelta(0, 32400)
>
> In [77]: tz._utcoffset
> Out[77]: datetime.timedelta(0, 33540)
>
In the first case tz.utcoffset has a reference date, and can select the
proper time offset, i.e. in 2011 this is 09:00, but tz._utcoffset
doesn't know which year it refers to, and hence, it picks one offset,
in this case the first on the list that has the additional 19 minutes
offset.
I do also not understand why the test fails only now though, and why
pandas picks one code path to define the test case, and another to
create the expected value.
Best,
Gert
Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
On Tue, 28 Mar 2017 15:18:20 +0200, Gert Wollny wrote: > I did some digging: > > Maybe it's a bug in python-tz? > Most likely: FWIW, python-tz also has a FTBFS bug: https://bugs.debian.org/858133 Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
Hello,
I did some digging:
> Maybe it's a bug in python-tz?
Most likely:
Pandas uses this code to get the time offset for the local time
in tslib.pyx:
cpdef _get_utcoffset(tzinfo, obj):
try:
return tzinfo._utcoffset
except AttributeError:
return tzinfo.utcoffset(obj)
Now with
tz = pytz.timezone('Asia/Tokyo')
dt = datetime.datetime(2011,1,1)
I get
In[76]: tz.utcoffset(dt)
Out[76]: datetime.timedelta(0, 32400)
In [77]: tz._utcoffset
Out[77]: datetime.timedelta(0, 33540)
which is exactly the 19 min difference we see, and the result depends
on the code path taken in _get_utoffset.
Best,
Gert
Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
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= 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= 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 NAMEGMTOFF RULES FORMAT [UNTIL]
Zone Asia/Tokyo 9:18:59 - LMT 1887 Dec 31 15:00u
- 9:00- JST 1896 Jan 1
- 9:00- JCST1937 Oct 1
9:00Japan 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
Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?
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. Kind regards Andreas. PS: Yaroslav, you know my opinion about using Vcs outside of debian.org and deriving from policies that are widely established. Currently git://github.com/neurodebian/pandas.git is not even featuring the latest uploads - last changelog entry is pandas (0.19.2-2) unstable; urgency=medium * Exclude a number of tests while running on non-amd64 platforms due to bugs in numpy/pandas -- Yaroslav Halchenko Wed, 11 Jan 2017 12:13:05 -0500 I'm sorry to repeat myself but you are not creating a welcoming environment for people who intend to help. -- http://fam-tille.de
