time module: why not using tzname from the glibc?

[vstinner]

BPO	35385
Nosy	@abalkin, @vstinner, @pganssle, @izbyshev

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-06-13.01:13:56.059>
created_at = <Date 2018-12-03.10:56:29.685>
labels = ['3.8', 'library', 'invalid']
title = 'time module: why not using tzname from the glibc?'
updated_at = <Date 2019-06-13.01:13:56.058>
user = 'https://github.com/vstinner'

bugs.python.org fields:

activity = <Date 2019-06-13.01:13:56.058>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-06-13.01:13:56.059>
closer = 'vstinner'
components = ['Library (Lib)']
creation = <Date 2018-12-03.10:56:29.685>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 35385
keywords = []
message_count = 5.0
messages = ['330932', '330933', '330944', '333026', '345447']
nosy_count = 4.0
nosy_names = ['belopolsky', 'vstinner', 'p-ganssle', 'izbyshev']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue35385'
versions = ['Python 3.8']

[vstinner]

Currently, the time module uses tm_zone and tm_gmtoff of struct tm with localtime_r() to get the timezone (name and offset) on my Fedora 29. But it seems like glibc provides "tzname", "daylight" and "timezone" variables. Why not using them?

Python also provides "altzone", I'm not sure how to get this value from the glibc. See also the documentation:

https://docs.python.org/dev/library/time.html#timezone-constants

It's not a bug, it's more a question :-)

It seems like the configure script always undefine HAVE_DECL_TZNAME:
---
/* Define to 1 if you have the declaration of `tzname', and to 0 if you don't.
*/
#undef HAVE_DECL_TZNAME
---

Example of C program:
---

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

int main()
{
    putenv("TZ=UTC");
    tzset();
    printf("tzname = {%s, %s}\n", tzname[0], tzname[1]);
    exit(EXIT_SUCCESS);
}

---

Output on Fedora 29, glibc 2.28:
---

tzname = {UTC, UTC}

---

Note: tzname is not always defined by <time.h>:
---
/* Defined in localtime.c. */
extern char *__tzname[2]; /* Current timezone names. */
extern int __daylight; /* If daylight-saving time is ever in use. */
extern long int __timezone; /* Seconds west of UTC. */

#ifdef	__USE_POSIX
/* Same as above.  */
extern char *tzname[2];

/* Set time conversion information from the TZ environment variable.
If TZ is not defined, a locale-dependent default is used. */
extern void tzset (void) __THROW;
#endif

#if defined __USE_MISC || defined __USE_XOPEN
extern int daylight;
extern long int timezone;
#endif

---

configure should try to tzname is available no?

For HAVE_WORKING_TZSET, configure contains a C program which uses HAVE_TZNAME. Extract:
---

#if HAVE_TZNAME
extern char *tzname[];
#endif
...
	putenv("TZ=UTC+0");
	tzset();
	if (localtime(&groundhogday)->tm_hour != 0)
	    exit(1);
#if HAVE_TZNAME
	/* For UTC, tzname[1] is sometimes "", sometimes "   " */
	if (strcmp(tzname[0], "UTC") ||
		(tzname[1][0] != 0 && tzname[1][0] != ' '))
	    exit(1);
#endif

---

I don't understand the test on the TZ=UTC+0 timezone: I get tzname[0]="UTC" and tzname[1]="UTC" which fails the test...

In Python 2.7, there is:
---
/* This code moved from inittime wholesale to allow calling it from
time_tzset. In the future, some parts of it can be moved back
(for platforms that don't HAVE_WORKING_TZSET, when we know what they
are), and the extraneous calls to tzset(3) should be removed.
I haven't done this yet, as I don't want to change this code as
little as possible when introducing the time.tzset and time.tzsetwall
methods. This should simply be a method of doing the following once,
at the top of this function and removing the call to tzset() from
time_tzset():

        #ifdef HAVE_TZSET
        tzset()
        #endif

And I'm lazy and hate C so nyer.
 */

#if defined(HAVE_TZNAME) && !defined(__GLIBC__) && !defined(__CYGWIN__)

---

The glibc is explicitly excluded from platforms which support "tzname". The "!defined(GLIBC)" test is quite old...

commit ea424e1
Author: Guido van Rossum <guido@python.org>
Date: Fri Apr 23 20:59:05 1999 +0000

Apparently __GNU_LIBRARY__ is defined for glibc as well as for libc5.
The test really wanted to distinguish between the two.  So now we test
for __GLIBC__ instead.  I have confirmed that this works for glibc and
I have an email from Christian Tanzer confirming that it works for
libc5, so it should be fine.

[vstinner]

Ah, context of this question: I modified get_gmtoff() in bpo-35373 to fix compiler warnings :-) (see my first commit 503ce5c)

[izbyshev]

See bpo-28108 and https://sourceware.org/bugzilla/show_bug.cgi?id=23859 (for msg276123).

[vstinner]

See also bpo-28108.

[vstinner]

This issue isn't really a bug. The current code just works. I close the issue.