jsaul jsaul at gmx.de
Tue Mar 11 08:49:55 CET 2003

* Tim Peters [2003-03-11 01:26]:
> > What you say is of course right w.r.t. the standardized members of
> > struct tm;
> If a C gimmick isn't in ANSI C, POSIX, or a platform-specific extension
> module, it doesn't exist to Python.

Full ACK, that's a strong point, of course.

> Mostly that C's treatment of time zones is a mess.  In Python 2.3's datetime
> module, datetime and time objects can be specified with an explicit tzinfo
> (time zone info) object, and they supply strftime() methods where Python
> processes %Z and %z codes itself, extracting the info from the tzinfo
> object.  That's sane.

Great. So there is no need to mess with timemodule.c then. I didn't
know about datetime. Time to upgrade.

> Before then, note that Python's time module already exports time.timezone,
> time.altzone, and time.daylight, on platforms that support them (not all
> do).  I suppose you could cobble together a platform-dependent hack out of
> those (same as you'd have to do if coding in C, really).

In fact I was already doing so, in a 'rfc822datestr()' function using
time.timezone. But I also wanted to know what this highly subtle
difference in the two ways to call time.strftime() was due to.

    email.Utils.formatdate(time.time(), 1)

seems to me the most elegant (and hopefully portable) solution.

Thanks to all who replied!

Cheers, jsaul
Palo pa'que aprenda que aquí sí hay honor!
[Rubén Blades]

More information about the Python-list mailing list