[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: I ran the attached test-mktime.c program on Linux and MacOS X with the following results (TZ=America/New_York): $ cat test-mktime.c #include #include static void print_globals(struct tm *tm) { printf("%04d-%02d: %s/%s (%s) %d %ld (%ld)\n", 19

[issue22798] time.mktime doesn't update time.tzname

Changes by Alexander Belopolsky : -- versions: +Python 3.7 -Python 3.4, Python 3.5, Python 3.6 ___ Python tracker ___ ___ Python-bugs-

[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: MAL> The fact that tzset() does update the module globals is not documented. See #28130. -- ___ Python tracker ___ __

[issue22798] time.mktime doesn't update time.tzname

Akira Li added the comment: Marc-Andre Lemburg 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 explicitl

Re: [issue22798] time.mktime doesn't update time.tzname

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 su

[issue22798] time.mktime doesn't update time.tzname

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

[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: Is there any platform where mktime resets global tzname but does not provide tm_zone? If not, OP's issue is largely theoretical, but I still like MAL's suggestion of using strftime("%Z") as a fall-back. -- __

[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: Akira, Would issue22798.diff patch address your issue? -- assignee: -> belopolsky resolution: not a bug -> stage: resolved -> patch review Added file: http://bugs.python.org/file40598/issue22798.diff ___ Pyth

[issue22798] time.mktime doesn't update time.tzname

Marc-Andre Lemburg added the comment: BTW: The most portable way to access the timezone name of a given local time is to use strftime() with %Z as format character. -- ___ Python tracker __

[issue22798] time.mktime doesn't update time.tzname

Marc-Andre Lemburg added the comment: mktime() does change several global C runtime variables on Linux. See the man page on http://linux.die.net/man/3/mktime However, the Python documentation does not mention anything about having time.tzname being tied to the C lib global: https://docs.pytho

[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: > C tzname changes on my machine after the corresponding C mktime() calls Did you run the code that I posted? If not - please do and report the results. (I think there is a valid issue behind all this, but you are not helping to reveal it. I suspect w

[issue22798] time.mktime doesn't update time.tzname

Akira Li added the comment: The C code produces correct values according to the tz database. If TZ=Europe/Moscow then tzname={"MSK", "MSD"} at 2010-07-01 and tzname={"MSK", "MSK"} at 2015-07-01. Notice the difference! The code calls C mktime() with corresponding time tuples and checks that *tzn

[issue22798] time.mktime doesn't update time.tzname

Changes by Alexander Belopolsky : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: > You should have run the attached test_mktime_changes_tzname.c ... I did run it and tried several times to understand what it does. It did not help. If you claim that calling mktime() changes the value of the global tzname variable, you should be able

[issue22798] time.mktime doesn't update time.tzname

Akira Li added the comment: > C mktime itself should not change timezone globals, but it may indirectly if > it calls tzset() and TZ changed between calls. You should have run the attached test_mktime_changes_tzname.c which demonstrates that (at least on some systems) C mktime *does* change tz

[issue22798] time.mktime doesn't update time.tzname

Alexander Belopolsky added the comment: C mktime itself should not change timezone globals, but it may indirectly if it calls tzset() and TZ changed between calls. I don't understand what this issue is about. Unlike C mktime, time.mktime is not documented to call time.tzset(). If you want to

[issue22798] time.mktime doesn't update time.tzname

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue22798] time.mktime doesn't update time.tzname

Changes by Akira Li <4kir4...@gmail.com>: Removed file: http://bugs.python.org/file37132/test_mktime_changes_tzname.c ___ Python tracker ___ _

[issue22798] time.mktime doesn't update time.tzname

Akira Li added the comment: One of the ways to fix this issue is to synchronize time.tzname attribute with the corresponding C tzname variable. I've uploaded sync-time-timezone-attr-with-c.diff patch that synchronizes tzname, timezone, altzone, daylight attributes. The patch also includes tests

[issue22798] time.mktime doesn't update time.tzname

Changes by Akira Li <4kir4...@gmail.com>: Added file: http://bugs.python.org/file37134/test_mktime_changes_tzname.c ___ Python tracker ___ ___

[issue22798] time.mktime doesn't update time.tzname

Akira Li added the comment: I've attached test-timezone-info-is-updated.diff file -- a patch for Lib/test/test_time.py that demonstrates that time functions fail to update the timezone info. The test uses Europe/Moscow timezone but most timezones around the world had/will have different tznam

[issue22798] time.mktime doesn't update time.tzname

New submission from Akira Li: time.tzname is initialized from C tzname variable or tm_zone around Jan, Jul of the current year. If time.mktime() is called with a time tuple from the past/future then after the call time.tzname might be out-of-sync with the corresponding C tzname and tm_zone va