Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug in time module - %z works in perl, not in python?

4 views
Skip to first unread message

bwoos...@gmail.com

unread,
Feb 21, 2007, 9:17:59 PM2/21/07
to
Following python code prints out incorrect UTC Offset - the python
docs say that %z is not fully supported on all platforms - but on
Linux Fedora FC5, perl code works and python does not - is this a bug
or is this expected behavior? For a EST timezone setup, Perl prints
correct -0500, while Python prints +0000 - this is Python 2.4.

Perl:
$now_string = strftime "%Y-%m-%d %H:%M:%S %Z%z", localtime;
print $now_string, "(iso local)\n";

2007-02-21 21:16:16 EST-0500 (iso localtime, perl)

Python:
now_string = time.strftime("%Y-%m-%d %H:%M:%S %Z%z", time.localtime())
print now_string, " (iso localtime, python)"

2007-02-21 21:15:58 EST+0000 (iso localtime, python)

Is this expected behavior, or a bug?

attn.st...@gmail.com

unread,
Feb 21, 2007, 9:50:20 PM2/21/07
to


Seems to be a bug. I can duplicate the
problem here (Python 2.4.3, Red Hat Desktop release 4).

I do see the correct output, however, if I pass just
the format string to strftime:

>>> print time.strftime("%Y-%m-%d %H:%M:%S %Z %z")
2007-02-21 18:42:03 PST -0800

>>> print time.strftime("%Y-%m-%d %H:%M:%S %Z %z", time.localtime())
2007-02-21 18:42:11 PST +0000

--
Hope this helps,
Steven

bwoos...@gmail.com

unread,
Feb 22, 2007, 11:29:04 AM2/22/07
to
On Feb 21, 9:50 pm, attn.steven....@gmail.com wrote:
> On Feb 21, 6:17 pm, bwooste...@gmail.com wrote:
...

> > 2007-02-21 21:15:58 EST+0000 (iso localtime, python)

> Seems to be a bug. I can duplicate the


> problem here (Python 2.4.3, Red Hat Desktop release 4).

I searched the bug database, found this issue was closed as not a bug.

I don't know if I should enter a new bug, for now, have just added a
comment to the above closure, not sure if anyone will look into
whether this issue should be reopened.

http://sourceforge.net/tracker/index.php?func=detail&aid=1493676&group_id=5470&atid=105470


[above bug says that %z (small z) is not supported by Python - that
seems to be incorrect, atleast to me. Capital Z may be deprecated, but
not small z as far as I can tell.]

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.

Paul Boddie

unread,
Feb 22, 2007, 12:23:32 PM2/22/07
to
On 22 Feb, 17:29, bwooste...@gmail.com wrote:
> On Feb 21, 9:50 pm, attn.steven....@gmail.com wrote:
>
> > On Feb 21, 6:17 pm, bwooste...@gmail.com wrote:
> ...
> > > 2007-02-21 21:15:58 EST+0000 (iso localtime, python)
> > Seems to be a bug. I can duplicate the
> > problem here (Python 2.4.3, Red Hat Desktop release 4).
>
> I searched the bug database, found this issue was closed as not a bug.

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. Trying to use the datetime module to
reproduce the problem seems to involve a need to produce "aware"
datetime objects, apparently requiring me to define my own tzinfo
class:

class mytz(datetime.tzinfo):
def utcoffset(self, dt):
return datetime.timedelta(minutes=60)
def dst(self, dt):
return datetime.timedelta(0)
def tzname(self, dt):
return "CET"

Only then will there be time zone or offset information on datetime
objects:

now = datetime.datetime.now(mytz())
now.strftime("%Y-%m-%d %H:%M:%S %z")
# produced '2007-02-22 18:14:41 +0100'

Some helper classes would really be useful for this kind of thing (and
I remember that there is a time zone database module out there
somewhere), but at least the time zone information gets through in the
end.

Paul

0 new messages