I don't know if this is a bug in datetime or in pytz,
so I submitted this as a bug with pytz as well:
https://sourceforge.net/tracker/index.php?func=detail&aid=1233776&group_id=79122&atid=555590

The first example does not give the result I expect.
The second does.

Python 2.3.4 (#1, Aug  6 2004, 18:12:39) 
[GCC 2.95.3 20010315 (SuSE)] on linux2
>>> from datetime import datetime
>>> from pytz import timezone
>>> utc = timezone('UTC')
>>> utc_dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=utc)
>>> print utc_dt
1970-01-01 00:00:00+00:00
>>> print utc_dt.strftime('%c * %Z * %s')
Thu Jan  1 00:00:00 1970 * UTC * -3600


Python 2.3.4 (#1, Aug  6 2004, 18:12:39) 
[GCC 2.95.3 20010315 (SuSE)] on linux2
>>> import os
>>> os.environ['TZ'] = 'UTC'
>>> from datetime import datetime
>>> from pytz import timezone
>>> utc = timezone('UTC')
>>> utc_dt = datetime(1970, 1, 1, 0, 0, 0, tzinfo=utc)
>>> print utc_dt
1970-01-01 00:00:00+00:00
>>> print utc_dt.strftime('%c * %Z * %s')
Thu Jan  1 00:00:00 1970 * UTC * 0

Logged In: YES 
user_id=11375

Given that tzinfo is coming from the pytz package, which is
external to Python, it seems unlikely that this is a Python
bug.  If the pytz developers ultimately track down the
problem to a Python bug, they can surely provide a test case
for Python that doesn't depend on external software.

Closing this bug; it can be reopened if it turns out to be a
Python problem.