Logged In: YES 
user_id=46639

This is a pytz issue, and a result of me abusing Tim's code
in ways he never intended. Tim is quite correct in that
there are actually several tzinfo instances under the
covers. In order to to unambiguous localtime calculations,
an extra bit of information needs to be known (the is_dst
flag in most datetime libraries). pytz uses the tzinfo
instance to store this bit of information. The side affects
of doing this are the behavior you noticed, and confusion as
constructing datetime instances needs to be done as per
pytz's README rather than the documented method in the
Python Library Reference.

>>> import pytz
>>> info = pytz.timezone('US/Central')
>>> info
<DstTzInfo 'US/Central' CST-1 day, 18:00:00 STD>
>>> from datetime import datetime
>>> now = info.localize(datetime.now(), is_dst=True)
>>> now
datetime.datetime(2006, 9, 8, 11, 19, 29, 587943,
tzinfo=<DstTzInfo 'US/Central' CDT-1 day, 19:00:00 DST>)
>>> t2 = info.localize(datetime(2006, 9, 8, 11, 19, 29, 587943))
>>> t2
datetime.datetime(2006, 9, 8, 11, 19, 29, 587943,
tzinfo=<DstTzInfo 'US/Central' CDT-1 day, 19:00:00 DST>)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
False
>>> now.tzinfo == t2.tzinfo
True

Last time I tried, it seemed impossible to support both
pytz's goals and the datetime construction API specified in
the Python Library Reference without extending the Python
datetime module (and I have yet to specify what would be
required).

If I was to add an __eq__ method to the tzinfo classes, I'm
not actually sure what the correct behavior should be.
Should US/Eastern Daylight Savings Time really equate to
US/Eastern Standard Time? Should US/Eastern Daylight Savings
Time in 2002 really equate to US/Eastern Daylight Savings
Time in 2007? The umbrella timezone might be the same, but
the UTC offsets or switchover dates are different.

The pytz bugtracker is at 
https://launchpad.net/products/pytz/+bugs