Bugs item #1493676, was opened at 2006-05-23 15:58 Message generated for change (Comment added) made by bwooster47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Cillian Sharkey (csharkey) Assigned to: Nobody/Anonymous (nobody) Summary: time.strftime() %z error Initial Comment: According to the time module documentation, if the time argument for strftime() is not provided, it will use the current time as returned by localtime(). However, when the value of localtime() is explicitly given to strftime(), this produces an error in the value of the timezone offset (%z) as seen here: >>> from time import * >>> strftime("%a %b %e %H:%M:%S %Y %Z %z") 'Tue May 23 16:28:31 2006 IST +0100' >>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime()) 'Tue May 23 16:28:31 2006 IST +0000' This same problem happens for other timezones (the offset is always +0000 when localtime() is explicitly given). This problem is present in both these versions: Python 2.4.2 (#2, Sep 30 2005, 21:19:01) [GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8)] on linux2 Python 2.3.5 (#2, Sep 4 2005, 22:01:42) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-23 15:38 Message: Logged In: YES user_id=1209659 Originator: NO To continue my previous comment, here's the snippet of a posting from comp.lang.python discussion, posted by "Paul Boddie": As far as I can see, the reason for the differing behaviour of time.strftime is due to the way any supplied tuple is processed: 1. In Modules/timemodule.c, the time_strftime function calls gettmarg. 2. In gettmarg, various fields of struct tm are filled in, except for tm_gmtoff and tm_zone/__tm_zone (according to /usr/include/time.h). 3. Consequently, any structure produced from a tuple may lack those fields, in contrast to such structures produced directly by the system calls. 4. Thus, the strftime system call fails to find or make use of time zone information. So it looks like no call to strftime with a supplied argument will produce time zone information. ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-23 15:20 Message: Logged In: YES user_id=1209659 Originator: NO But the C library does support it (and ones that don't will start - +nnnn is ISO format, and frankly, I don't know a C library that does not support it, though I'm sure some exist). The question is different - as the original post shows: >>> strftime("%a %b %e %H:%M:%S %Y %Z %z") 'Tue May 23 16:28:31 2006 IST +0100' >>> strftime("%a %b %e %H:%M:%S %Y %Z %z", localtime()) 'Tue May 23 16:28:31 2006 IST +0000' Python has clearly used the C-library to get correct data in the first code path through strftime, but there is a second code path that prints wrong data. Someone posted code analysis in comp.lang.python explaining this, maybe that can be used as a starting point for a patch to fix the two code paths in Python strftime to work the same? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2007-02-23 14:25 Message: Logged In: YES user_id=357491 Originator: NO It is not a Python issue. strftime is a very thin wrapper to the underlying C implementation, so if the C library doesn't support %z, neither does Python. You can write a patch if you want to cause it to blank out if it is not supported and submit it. ---------------------------------------------------------------------- Comment By: bwooster47 (bwooster47) Date: 2007-02-22 16:22 Message: Logged In: YES user_id=1209659 Originator: NO Can we confirm whether this issue is not a python issue? We are talking about small z, not capital Z. >From Python docs at http://docs.python.org/lib/module-time.html : "The use of %Z is now deprecated, but the %z escape that expands to the preferred hour/minute offset is not supported by all ANSI C libraries." Most current C libraries support %z, it is in fact the preferred way to do things, would be bad to see python reject this. Even then - isn't the above a bug? If not supported, %z should always provide a empty character, but not print out totally incorrect data as +0000 for EST. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-05-24 21:26 Message: Logged In: YES user_id=357491 Closing as invalid since, as Georg pointed out, %z is not supported by Python. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-05-23 16:58 Message: Logged In: YES user_id=849994 Note that %z isn't officially supported by Python, judging by the docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1493676&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com