Akira Li added the comment:
Marc-Andre Lemburg <rep...@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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22798>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
