Adds access to the tzset method, allowing you to change your local timezone as required. In addition to invoking the tzset system
call, the code also updates the timezone attributes (time.timezone etc). This lets you do timezone conversions amongst other things.

Also includes changes to configure.in to only build new code if the tzset method correctly switches timezones on your platform. This 
should be for all modern Unixes, and possibly other platforms.

Also includes tests in test_time.py

Docs would be along the lines of:

tzset() -- 
Initialize, or reinitialize, the local timezone to the value stored in os.environ['TZ']. The TZ environment variable should be specified in
standard Uniz timezone format as documented in the tzset man page
(eg. 'US/Eastern', 'Europe/Amsterdam'). Unknown timezones will silently fall back to UTC. If the TZ environment variable is not set, the local timezone is set to the systems best guess of wallclock time.
Changing the TZ environment variable without calling tzset *may* change the local timezone used by methods such as localtime, but this behaviour should not be relied on.

eg::

>>> now = time.time()
>>> os.environ['TZ'] = 'Europe/Amsterdam'
>>> time.tzset()
>>> time.ctime(now)
'Mon Jan 27 14:35:17 2003'
>>> time.tzname  
('CET', 'CEST')
>>> os.environ['TZ'] = 'US/Eastern'
>>> time.tzset()
>>> time.ctime(now)
'Mon Jan 27 08:35:17 2003'
>>> time.tzname
('EST', 'EDT')

Logged In: YES 
user_id=46639

Assigning to Guido for consideration of being added to
2.2.3, and since he through this patch was a good idea in
the first place :-)

Logged In: YES 
user_id=6380

Uh? This is a new feature, so doesn't apply to 2.2.3.

Maybe you meant 2.3?

Logged In: YES 
user_id=46639

It is a patch to 2.3, but I'd though I'd try and sneak this
new feature past people into 2.2.3 as I want to be able to
use it in Zope 2 :-)

Logged In: YES 
user_id=6380

Sorry, not a chance.

Logged In: YES 
user_id=6380

zenzen: when I run the test suite on my Red Hat Linux 7.3
box, I get one failure: the test line
  self.failUnless(time.tzname[0] in ('UTC','GMT'))
fails when the timezone is set to 'Luna/Tycho', because
tzname is in fact set to  ('Luna/Tych', 'Luna/Tych').

If I comment out that one line the tzset test suite passes.

What should I do?

Logged In: YES 
user_id=46639

Leave it commented out or remove that line. It is testing
unimportant behaviour that looks more platform dependant
than I suspected (and now I look at it again, what tzname
should be set to if the timezone is unknow is unspecified by
the tzset(3) docs). The important behaviour is that:

a) the system silently falls back to UTC if the timezone is
unknown, and this is tested elsewhere 

b) calling tzset resets tzname, which is also tested elsewhere.

Logged In: YES 
user_id=6380

OK, checked in with that line removed.

Thanks!

Logged In: YES 
user_id=33168

test_time is now failing on Solaris 8.  altzone is -3600,
but should be 0.  Also, is there a reason to compare
timezone to altzone, but then check that each is 0 (line
78)?  Can you provide any suggestions for where to look for
the problem?

Logged In: YES 
user_id=46639

An update to this patch is now available:
http://www.python.org/sf/706707

Logged In: YES 
user_id=33168

Closing again, the problem can be addressed thru the other
patch.