Marc-Andre Lemburg <report@bugs.python.org> writes:
...
> tzname is set when the module is being loaded and not updated
> afterwards (unless you call tzset()). I can't really see why you
> would expect a module global in Python to follow the semantics
> of a C global, unless this is explicitly documented.

Python docs recommend reading platform docs.
Platform docs say that mktime() may change tzname.
Python docs do not contradict.

Why wouldn't I assume that mktime() may change tzname?

> Note: The fact that tzset() does update the module globals is
> not documented.

It is documented e.g., I see: "These will be propagated into
time.tzname" in tzset() docs.

Though tzset() has nothing to do with the issue (TZ envvar hasn't been
changed).

>> Unrelated: time.strftime('%Z') and
>> time.strftime('%Z', time.localtime(time.time())) can differ on some 
>> platforms and python versions
>>   http://stackoverflow.com/questions/32353015/python-time-strftime-z-is-always-zero-instead-of-timezone-offset
>
> The StackOverflow discussion targets %z (lower case z),
> not %Z (with capital Z).

Look at the answers. The examples clearly shows both %Z and %z.

> I think this is just a documentation bug.
>
> Overall, I think that relying on those module globals is
> not a good idea. They are not threadsafe and their values
> can only be trusted right after module import. It's much
> safer to access the resp. values by using struct_time values
> or strftime().
>

Agree. Moreover, you can't trust them even "right after module import"
sometimes.

Though, some predictability in the behavior such as "time.tzname is
whatever C tzname is -- consult the platform docs" would be nice.