time.strftime()

[Tim Peters]

[jsaul]
> ...
> In fact, "%z" appears to be an extension of the GNU-libc. But
> it is also specified by IEEE Std 1003.1-2001 aka POSIX.1-2001.

Also by C99.

> Anyway, since I am on a GNU-libc system, I would expect either a
> proper conversion or no conversion at all. So it appears to be
> interpreted and it actually *is*, see below...
>
> ...
> *But* I was too hasty and while I relied on the apparently
> somewhat incomplete information provided by help(time), I should
> have read the more exhaustime html-docs. It turns out that I can
> invoke time.strftime() without a second argument; the current
> local time is used then. And this results in the correct output:
>
> >>> time.strftime("%z")
> '+0100'
>
> Wow. On the other hand:
>
> >>> time.strftime("%z", time.localtime())
> '+0000'
>
> Thus it actually could not have worked the way I tried it, because
> the tuple returned by time.localtime() contains no information
> about the time zone, therefore obviously no proper output from
> "%z" was possible.

strftime can't be passed time zone info directly, no matter how it's called:
its struct tm input simply doesnt't have any time zone info beyond the
tm_isdst flag.  strftime gets all time zone info from the current locale;
the tuple passed to it determines only whether daylight time is in effect
(via the tm_isdst flag).

> The way this is describge in the html-docs is a bit misleading,
> IMHO: "If tuple is not provided, the current time as returned by
> localtime() is used." But both cases are *not* equivalent, as the
> tuple lacks time zone information.

Read the C code if you really want to know what's going on.  You're going to
have to anyway to figure out what's going wrong on your box <0.9 wink>.  The
cases should indeed be equivalent, but only God knows how locale can get
screwed up on your box.