[Patches] [ python-Patches-762963 ] timemodule.c: Python loses current timezone
SourceForge.net
noreply@sourceforge.net
Thu, 10 Jul 2003 11:14:43 -0700
Patches item #762963, was opened at 2003-06-30 02:18
Message generated for change (Comment added) made by quale
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470
Category: Modules
Group: None
>Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Doug Quale (quale)
Assigned to: Brett Cannon (bcannon)
Summary: timemodule.c: Python loses current timezone
Initial Comment:
Python routines in timemodule.c sometimes force glibc
to use GMT instead of the correct timezone.
I think this is a longstanding bug, but I have only
looked at Python 2.2 and 2.33b1. This bug has been
reported before (510218) but it was misdiagnosed and
closed. It also came up recently in on the python-list
(http://aspn.activestate.com/ASPN/Mail/Message/python-list/1564384)
where it was also misdiagnosed.
Standard C and Python use a struct tm with 9 values.
BSD influenced C libraries like glibc have an extra
field (tm_gmtoff) that keeps the offset from UTC.
BSD-style struct tm values know the correct timezone
associated with the time, but Python and Standard C
struct tm values don't so they can only assume the
current timezone.
Ideally Python would always treat stuct tm-style time
tuples as being associated with the current timezone.
Unfortunately in many cases Python forces glibc to use
GMT rather than the current timezone. You can see the
problem most graphically with the %z format in
strftime(). In the transcript Python incorrectly gives
the timezone offset as +0000 even though it gets the
timezone name (CDT) correct:
$ python2.3
Python 2.3b1+ (#2, Jun 4 2003, 03:03:32)
[GCC 3.3 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import time
>>> now = time.localtime()
>>> print now
(2003, 6, 29, 20, 3, 52, 6, 180, 1)
>>> RFC822 = '%a, %d %b %Y %T %z'
>>> print time.strftime(RFC822, now)
Sun, 29 Jun 2003 20:03:52 +0000
>>> print time.strftime(RFC822)
Sun, 29 Jun 2003 20:05:27 -0500
>>> print time.strftime('%Z', now)
CDT
The correct timezone is CDT and the correct offset is
-0500. Notice that when time.strftime() computes the
current time it it gets the correct timezone offset,
but when the struct tm tuple is passed in it thinks the
timezone offset is 0. (glibc does know that the
correct timezone name is CDT even when passed a bad
struct tm value, but that's not surprising since the
timezone name is not stored in struct tm and it is not
computed from timezone offset.)
The problem is in the gettmargs() function in
timemodule.c. When getmargs() parses a Python tm tuple
it leaves the tm_gmtoff field zeroed. This specifically
tells glibc that the timezone offset is 0, which is
wrong for most people. (BSD libc may also be affected.)
This problem does not occur when time_strfrtime() gets
the current time itself since that codepath uses a
struct tm value directly from the libc localtime(),
leaving the tm_gmtoff field intact.
Fortunately the fix is almost trivial. A call to
mktime() will normalize the fields in the struct tm
value, including the tm_gmtoff field. I
conditionalized the patch only on HAVE_MKTIME. I'm
pretty sure there's an autoconfigure test for tm_gmtoff
and it would probably be better to use that.
----------------------------------------------------------------------
>Comment By: Doug Quale (quale)
Date: 2003-07-10 18:14
Message:
Logged In: YES
user_id=812266
The problem isn't in strftime. The problem is in gettmargs() in
timemodule.c.
Python assumes that broken down time tuples are in the local
timezone. The gettmargs() routine in timemodule.c is bugged
on GNU libc and possibly other BSD-inspired C libraries.
gettmargs() is supposed to take a Python broken down time
tuple and convert it to a C struct tm. The Python time tuple
is assumed to be in the local time zone, so the struct tm
should be in the local timezone also. In glibc, struct tm has
timezone fields so each struct tm knows its own timezone.
The gettmargs() routine never fills in these extra fields so it
always creates a struct tm in GMT. The appropriate behavior
would be to set tm_gmtoff to the local timezone offset. My
patch fixes gettmargs() to create struct tm's in the local
timezone for C libraries that have the tm_gmtoff field in struct
tm.
As to the docs issue, the Python docs say that other formats
may be supported than the ones listed. In reality, strftime() is
passed to the underlying C library so the format codes
supported are whatever the C library supports. The doc
statement "Additional directives may be supported on certain
platforms, but only the ones listed here have a meaning
standardized by ANSI C" is wrong, or at least not up to date.
C99 specifies several strftime format codes that are not listed
including %z. I think Tim Smith also mentions this in a Python
list posting from earlier this year.
In the Python time module, the docs say strftime('format') is
the same as strftime('format', localtime()). This is simply
broken right now on glibc as has been reported by more than
one person:
>>> strftime('%z')
'-0500'
>>> strftime('%z', localtime())
'+0000'
This is wrong. Unsupported format specifiers do not have this
effect, for example:
>>> strftime('%L')
'%L'
>>> strftime('%L', localtime())
'%L'
This behavior is correct.
A final note on the patch: I should have looked closer at the
timemodule.c source. It already uses the appropriate #ifdef in
other places. Instead of #ifdef HAVE_MKTIME my patch
should be conditionalized #ifdef HAVE_STRUCT_TM_TM_ZONE.
It's kind of amusing to write up this long of a justification for
what is essentially a 3 line patch.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2003-07-09 22:36
Message:
Logged In: YES
user_id=357491
So the problem is with the %z directive not reporting the proper
timezone offset, correct? If you look at http://www.python.org/
dev/doc/devel/lib/module-time.html , though, you will notice that
%T is not supported as a directive for strftime or strptime nor has
it ever been supported. Same goes for %T although it works in
your example.
Since the docs do not say that these directives are supported I am
closing this patch since it would require altering both strftime and
stprtime to support %z on all platforms which this patch does not.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=762963&group_id=5470