On 29.09.2015 11:31, Akira Li wrote:
> 
> Akira Li added the comment:
> 
>> Would issue22798.diff patch address your issue?
> 
> No. The issue is that C mktime() may update C tzname on some platforms
> but time.mktime() does not update time.tzname on these platforms while 
> the time module docs suggest that it might be expected e.g.:
> 
>   Most of the functions defined in this module call platform C library
>   functions with the same name. It may sometimes be helpful to consult
>   the platform documentation, because the semantics of these functions 
>   varies among platforms.

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.

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

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

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