[ python-Bugs-1493676 ] time.strftime() %z error

[SourceForge.net]

Bugs item #1493676, was opened at 2006-05-23 08:58
Message generated for change (Comment added) made by bcannon
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: Brett Cannon (bcannon)
Date: 2007-02-23 09:23

Message:
Logged In: YES 
user_id=357491
Originator: NO

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).

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

Comment By: bwooster47 (bwooster47)
Date: 2007-02-23 07: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 07: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 06: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 08: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 14: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 09: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