Python's time module seems to get the timezone name
when it's
first imported, but it doesn't change it if the TZ
environment
variable is later set.  On the other hand, the time of
day DOES
change accordingly.  Thus, setting TZ after the time
module is
imported results in a completely broken rfc2822 date -
time in the
new TZ, but with a bogus UTC offset and timezone
(neither the old
nor new).

Here is the problem illustrated.  You will see that
after setting TZ,
altzone, timezone, and tzname don't change, while
asctime does.

$ python2.2
Python 2.2b2 (#1, Nov 18 2001, 18:20:32) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time,os
>>> print time.asctime()
Thu Nov 29 18:47:39 2001
>>> print time.altzone,time.timezone,time.tzname
21600 25200 ('MST', 'MDT')
>>> 
>>> os.environ['TZ'] = "Pacific/Auckland"
>>> print time.asctime()
Fri Nov 30 14:47:52 2001
>>> print time.altzone,time.timezone,time.tzname
21600 25200 ('MST', 'MDT')

Here is an example of why this is a problem in
practice.  One of
my applications sets the TZ environment variable based
on a
"TIMEZONE" setting in the user's configuration file. 
It later uses
the `email' module to create a "Date:" header for
outgoing mail
messages.  Because of this bug, the resulting "Date:"
is bogus.
 e.g,

$ python2.2
Python 2.2b2 (#1, Nov 18 2001, 18:20:32) 
[GCC 2.95.3 20010315 (release) [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for
more information.
>>> import email,os
>>> print email.Utils.formatdate(localtime=1)
Thu, 29 Nov 2001 18:52:34 -0700
>>> 
>>> os.environ['TZ'] = "Pacific/Auckland"
>>> print email.Utils.formatdate(localtime=1)
Fri, 30 Nov 2001 14:52:41 -0600

The `-0600' should be `+1300', and `-0600' isn't
correct even for the original timezone!

You might say: "Work around this by setting TZ before
the time
module is first imported." -- No, that is too fragile,
and too difficult
to do with complex applications.  Many other modules in
turn
import time, etc.  I suggest instead that the TZ
environment
variable be consulted each time the timezone is
accessed.