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().
--
Marc-Andre Lemburg
eGenix.com
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
