[Python-bugs-list] [ python-Feature Requests-487331 ] time mod's timezone doesn't honor TZ var
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 11 Dec 2001 01:45:49 -0800
Feature Requests item #487331, was opened at 2001-11-29 18:09
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=487331&group_id=5470
>Category: None
>Group: None
Status: Open
Priority: 3
Submitted By: Jason R. Mastaler (jasonrm)
>Assigned to: Nobody/Anonymous (nobody)
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-05 16:34
Message:
Logged In: YES
user_id=85984
Marc-André, I apologize for previously misspelling your
name a bunch of times. Oops.
----------------------------------------------------------------------
Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-05 15:58
Message:
Logged In: YES
user_id=85984
Mark,
To answer your question from a couple days ago,
my exact requirements are: The ability to produce
an rfc2822 compliant "Date" string that corresponds
to the current value of 'TZ' in the environment.
I'm currently using email.Utils.formatdate() to
produce the Date, but this breaks as soon as I set
'TZ' within my application. Setting 'TZ' from
within Python is necessary. I don't currently
know of a way to get around this problem as the
breakage is in the lower level time module.
Again, mxDateTime is NOT an option. Whether it
integrates nicely with Python and runs on many
platforms is not relevant. I'm sure both of these
facts are true, but I don't want my application to
depend on any external packages. This complicates
the installation procedure unnecessarily.
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-05 01:37
Message:
Logged In: YES
user_id=38388
Agreed. Let's continue to talk about this after Python 2.2 is out.
----------------------------------------------------------------------
Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-04 08:11
Message:
Logged In: YES
user_id=12800
Rightt, all I was thinking about was an object/function to
encapsulate the numeric timezone values, daylight, timezone,
and altzone, without sucking in all fo the timezone names
and abbreviations.
As for mxDateTime, yeah putting that into Python would
probably mean some compromise on the projmgt side of things.
OTOH, it would be damn handy! :)
Oh well, plenty of time to think about this for Python 2.3!
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-04 07:48
Message:
Logged In: YES
user_id=38388
Well, this may sound easy, but once you get into timezones things start to become one big can of worms, e.g.
just have a look at how daylight savings time is handled in different countries of the world or how time zone names
sometimes map to multiple different zones.
OTOH, numeric timezones are easy to handle and all that is needed is some simple code to convert a ticks value
plus an offset to a nice ISO string representation an vice-versa. That should be easy to add to the time module...
About adding mxDateTime to the core: I suppose it's simply too big. Also, I have a slightly different way of
maintaining the mx tools than what is considered the Python way -- I usually happily add new features and
modules without much fuzz; wouldn't want to have to write a PEP to enhance my own stuff ;-)
As compromise, I could add some ISO date/time parsing and formatting code from mxDateTime to Python 2.3.
----------------------------------------------------------------------
Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-04 07:04
Message:
Logged In: YES
user_id=12800
BTW, one way to possibly handle this would be to add
something to time module that created a "timezone object",
encapsulating daylight, timezone, and altzone for arbitrary
timezones. Then date producing code like
email.Utils.formatdate() could take optional timezone
objects to produce dates relative to the given zone.
----------------------------------------------------------------------
Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-04 07:03
Message:
Logged In: YES
user_id=12800
OT, but what about adding mxDateTime to core Python <2.3 wink>?
----------------------------------------------------------------------
Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-04 01:36
Message:
Logged In: YES
user_id=38388
Jason, as I already mentioned in my other reply, exposing tzset() to Python would cause more trouble than do any
good because of the side-effects it has.
Rather then provide ways to write buggy code in Python, I suggest to look into solving the problem you seem to
have using the available tools, e.g. mxDateTime runs on many different platforms and integrates nicely with
Python.
If the email package is the only one you need fixed, I suggest to write a small helper or patch which implements
the needed modifications for this package. BTW, what are you exact requirements ?
----------------------------------------------------------------------
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=355470&aid=487331&group_id=5470