[Python-bugs-list] [ python-Bugs-487331 ] time mod's timezone doesn't honor TZ var

[noreply@sourceforge.net]

Bugs item #487331, was opened at 2001-11-29 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 3
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: M.-A. Lemburg (lemburg)
Summary: time mod's timezone doesn't honor TZ var

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-03 13:56

Message:
Logged In: YES 
user_id=85984

I'm fairly ignorant of the gory details behind
the scenes of the time module, but I still contend
this is buggy behavior.  That is, setting
os.environ['TZ'] in the application totally
breaks higher level methods such as 
email.Utils.formatdate().

Barry had a suggestion which Mark doesn't think
is a good idea.  Mark, are you sure there isn't 
anything that can be done?  If think that if you 
disregard this issue, it will come back to haunt
the Python community.

With regards to your suggestion of mxDateTime:
I really can't consider this as I don't want to
rely on any external modules or packages.  
One of my application's strengths is that it 
"just works" out of the box with Python, so it's
very easy to install.  I'd like to keep it that
way unless it's absolutely necessary to do otherwise.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-30 12:53

Message:
Logged In: YES 
user_id=38388

I don't know whether this is such a good idea -- after all it's fairly easy to manage timezones in the application 
rather than trying to fiddle the C libs routines into producing the output you intend. Also note that tzset() is *not* 
thread safe.

BTW, Jason, you may want to have a look at mxDateTime -- perhaps it already has what you are looking for.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-11-30 12:11

Message:
Logged In: YES 
user_id=12800

Perhaps we should expose tzset() to Python?  We'd also have
to reset timezone, altzone, daylight, and tzname in the
module after calling tzset().

It's a bit of work, and adds a feature so it can't go into
Python 2.2, but if you think this is a viable approach,
re-assign this bug to me and I'll deal with it for Python 2.3.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-30 11:01

Message:
Logged In: YES 
user_id=38388

The time module is a very thin layer on top of the C lib time APIs. There's nothing much Python can do about 
errors in those APIs, e.g. not recognizing changes to TZ.

Also note that the tzset() API which inits the time APIs w/r to the TZ environment variable is only called at time 
module import time. To expose the dynamic changes you are looking for, it would have to call tzset() prior to all 
calls to asctime() et al. -- much too time consuming !

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487331&group_id=5470