Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Rebecca N. Palmer]

The underlying issue (but not strictly a bug as the documentation 
specifically says not to do that - 
http://sources.debian.net/src/python-tz/2016.7-0.2/pytz/tzinfo.py/#L247 
) is that passing a pytz tzinfo to the datetime constructor uses its 
first listed offset, not its correct offset for that date:

 >>> datetime.datetime(2017,4,1,tzinfo=pytz.timezone('Europe/London'))
datetime.datetime(2017, 4, 1, 0, 0, tzinfo=<DstTzInfo 'Europe/London' 
GMT0:00:00 STD>)
 >>> pytz.timezone('Europe/London').localize(datetime.datetime(2017,4,1))
datetime.datetime(2017, 4, 1, 0, 0, tzinfo=<DstTzInfo 'Europe/London' 
BST+1:00:00 DST>)

This suggests the attached fix, but this has *not* been tested.

As for why it's only now showing up...there seems to be something weird 
going on where the initial 'LMT' entries of timezone definitions 
sometimes get loaded into pytz.timezone objects but often don't:
jessie>>> pytz.timezone('Asia/Tokyo')._tzinfos
{(datetime.timedelta(0, 32400), datetime.timedelta(0), 'JST'): 
<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>, (datetime.timedelta(0, 32400), 
datetime.timedelta(0), 'JCST'): <DstTzInfo 'Asia/Tokyo' JCST+9:00:00 
STD>, (datetime.timedelta(0, 36000), datetime.timedelta(0, 3600), 
'JDT'): <DstTzInfo 'Asia/Tokyo' JDT+10:00:00 DST>}
sid>>> pytz.timezone('Asia/Tokyo')._tzinfos
{(datetime.timedelta(0, 32400), datetime.timedelta(0), 'JST'): 
<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>, (datetime.timedelta(0, 36000), 
datetime.timedelta(0, 3600), 'JDT'): <DstTzInfo 'Asia/Tokyo' 
JDT+10:00:00 DST>, (datetime.timedelta(0, 33540), datetime.timedelta(0), 
'LMT'): <DstTzInfo 'Asia/Tokyo' LMT+9:19:00 STD>}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 858260.patch
Type: text/x-diff
Size: 1572 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-zope-developers/attachments/20170401/3f615699/attachment.patch>