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

Logged In: YES 
user_id=849994

Note that %z isn't officially supported by Python, judging
by the docs.

Logged In: YES 
user_id=357491

Closing as invalid since, as Georg pointed out, %z is not
supported by Python.

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.

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.

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?

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. 

OK, but that is an issue of how much information is stored in the time tuple.  There is no UTC offset or timezone information stored in the tuple beyond whether DST is on or not.  That is just an inherit shortcoming of the time tuple.  You can't fix that without adding a new field to the time tuple itself.

I am personally not about to do that, but if someone wants to write a patch it might be considered.  But you will also need to discuss why this should be done over just moving to datetime (and possibly fixing it there if there are problems there as well).

Thanks, I'll let this go. (datetime is even worse - it does not handle any timezone data, and requires users to create their own timezone info).

So right now Python has no support for the functions that are readily available to GNU C-lib users of time, that's that, and I won't argue about it, will just assume Python cannot produce RFC 822 conformant dates with standard libraries. (Perl, PHP, all work fine (but they are not Python)).

(C-lib strftime has no problems printing %z with the time-tuple - with just dst info - because it is supposed to be the local time zone as set on the computer. No data needed in the tuple.
From the man page:
       %z     The  time-zone  as  hour  offset  from  GMT.   Required  to emit
              RFC 822-conformant dates (using "%a, %d  %b  %Y  %H:%M:%S  %z").
              (GNU)
)

It's probably too late to change details of the time tuple (far too much code now depends on it), but I have patches against 2.4.4 which provide an additional function called localtime_tz, which itself returns a localtime tuple containing the additional "GMT offset" field. With some modifications to various internal functions, the "struct tm" data can be populated and strftime can then produce the desired result.

With regard to datetime, it does support time zones, but there's a relatively large of work required to get "aware" datetime objects. I noted this situation in the referenced newsgroup message on this topic.

See patch #1667546 for a somewhat tested implementation of the changes mentioned below.

Hi all, glad to see this bug is being addressed!

Paul - thanks for your work, I hope your patching efforts make it into the tree.