On 22 Feb, 17:29, [EMAIL PROTECTED] wrote:
> On Feb 21, 9:50 pm, [EMAIL PROTECTED] wrote:
>
> > On Feb 21, 6:17 pm, [EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
