[issue35385] time module: why not using tzname from the glibc?

[STINNER Victor]

STINNER Victor  added the comment:

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

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35385] time module: why not using tzname from the glibc?

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-28108.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35385] time module: why not using tzname from the glibc?

[Paul Ganssle]

Change by Paul Ganssle :


--
nosy: +p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35385] time module: why not using tzname from the glibc?

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

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

--
nosy: +izbyshev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35385] time module: why not using tzname from the glibc?

[STINNER Victor]

STINNER Victor  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35385] time module: why not using tzname from the glibc?

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35385] time module: why not using tzname from the glibc?

[STINNER Victor]

New submission from STINNER Victor :

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 
#include 
#include 

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 :
---
/* 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 ea424e19f152638260c91d5fd6a805a288c931d2
Author: Guido van Rossum 
Date:   Fri Apr 23 20:59:05 1999 +

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.

--
components: Library (Lib)
messages: 330932
nosy: vstinner
priority: normal
severity: normal
status: open
title: time module: why not using tzname from the glibc?
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com