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

Discussion in 'Python' started by bwooster47@gmail.com, Feb 22, 2007.

  1. Guest

    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?
     
    , Feb 22, 2007
    #1
    1. Advertising

  2. Guest

    On Feb 21, 6:17 pm, wrote:
    > 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?





    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
     
    , Feb 22, 2007
    #2
    1. Advertising

  3. Guest

    On Feb 21, 9:50 pm, wrote:
    > On Feb 21, 6:17 pm, 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.
     
    , Feb 22, 2007
    #3
  4. Paul Boddie Guest

    On 22 Feb, 17:29, wrote:
    > On Feb 21, 9:50 pm, wrote:
    >
    > > On Feb 21, 6:17 pm, 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
     
    Paul Boddie, Feb 22, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. vm_usenet
    Replies:
    0
    Views:
    350
    vm_usenet
    Jul 2, 2003
  2. F. GEIGER
    Replies:
    3
    Views:
    816
    F. GEIGER
    Aug 6, 2004
  3. flamesrock
    Replies:
    8
    Views:
    555
    Hendrik van Rooyen
    Nov 24, 2006
  4. Alexander Burger

    getMethod() works and works not

    Alexander Burger, Nov 27, 2010, in forum: Java
    Replies:
    25
    Views:
    1,855
    Alexander Burger
    Nov 29, 2010
  5. abargaddon
    Replies:
    1
    Views:
    219
    clintmazur
    Feb 4, 2008
Loading...

Share This Page