time.strftime()

[Tim Peters]

[Tim]
> 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).

[jsaul]
> Sorry, but I have to contradict.

You can, but it won't do you any good <wink>.

> 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.

> however, it does have an extra tm_gmtoff member on some Unices.

Sure, but that won't do you any good from Python, unless someone has written
a platform-specific extension module to get at the non-standard extensions.

> ...
> Not the locale, fortunately... Sometimes one has to read the
> system header files as well. But it turned out that actually it
> *is* a bug in... timemodule.c? GNU-libc's strftime?

timemodule.c sticks to standard C here.  I have no idea how glibc intends
its gimmicks to be used, though.

> It's more of a subtle inconsistency than a bug perhaps; however,
> on systems where struct time has that member tm_gmtoff, it is
> apparently (generally?) necessary to fill it with the appropriate
> offset value to obtain the correct output for the "%z" specifier.

If so, they're guaranteeing that non-portable code is required.

> C99 requires an 'extern long timezone;' in time.h;

I don't believe this.  POSIX requires timezone, but not C99.  The latter
specifies that appropriate local info is to be gotten from the LC_TIME
category of the current locale.

> in time.h; this value represents seconds *west* of UTC, i.e. '-timezone'
> would have to be used to set tm_gmtoff, I believe. Or one simply
> initializes it in a way like:
>
>        time_t tt = time(NULL);
>        buf = *localtime(&tt);
>        if (tup != NULL) {
>                if (!gettmarg(tup, &buf))
>                        return NULL;
>        }
>
> *and* removal of the memset in gettmarg()instead of
>
>        if (tup == NULL) {
>                time_t tt = time(NULL);
>                buf = *localtime(&tt);
>        } else if (!gettmarg(tup, &buf))
>                return NULL;
>
> in "timemodule.c". Any comments?

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.

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).