New submission from Alexey Izbyshev <izbys...@ispras.ru>:

I've got the following on OpenSUSE Tumbleweed (glibc 2.27):

======================================================================
FAIL: test_TimeRE_recreation_timezone (test.test_strptime.CacheTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch2/izbyshev/cpython/Lib/test/support/__init__.py", line 1683, in 
inner
    return func(*args, **kwds)
  File "/scratch2/izbyshev/cpython/Lib/test/test_strptime.py", line 702, in 
test_TimeRE_recreation_timezone
    self.assertEqual(tm.tm_isdst, 1)
AssertionError: 0 != 1

This test sets TZ environment variable to 'STD-1DST' and calls time.tzset() 
(inside support.run_with_tz decorator). This TZ value lacks rules that specify 
when DST transitions happen. POSIX seems to be silent what should be done if 
the rule is missing, thought it does specify that the rule is optional[1].

What actually happens at least on Linux/glibc[2] and FreeBSD[3] is that those 
rules are taken from 'posixrules' file. On OpenSUSE, it's linked to 
'/etc/localtime', which is linked to 'Europe/Moscow' in my case. DST 
transitions were cancelled in Russia in 2011, so when Python tries to get 
timezone names for two points of the year 
(https://github.com/python/cpython/blob/570e371fd6e8615ece9b9e21fbe77149ebeb172e/Modules/timemodule.c#L1603),
 it gets unexpected values instead. The actual values depend on the bugginess 
of the libc used:

* Glibc seems to be confused by having 'posixrules' file with DST cancelled but 
a specification which includes the DST timezone part, so localtime() returns 
'MSK' in tm_zone (both for January and July).

* musl doesn't implement 'posixrules' fallback, so it uses "all-zero" rules 
instead which cause it return 'DST' in both cases.

* FreeBSD 11.1 (with 'posixrules' linked to 'Europe/Moscow') returns 'STD' in 
both cases.

With any of the above, the test fails because strptime is called with the same 
timezone name two times.

Note that even if PyInit_timezone() didn't probe January/July and used 'tzname' 
global instead, it wouldn't work as expected at least on FreeBSD: it sets 
tzname[1] to the empty string in the test above.

ISTM the best way to fix this is to remove dependence on 'posixrules' file by 
specifying the rules in TZ.

[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
[2] http://man7.org/linux/man-pages/man3/tzset.3.html
[3] https://www.freebsd.org/cgi/man.cgi?query=tzset&sektion=3

----------
components: Tests
messages: 329320
nosy: benjamin.peterson, izbyshev, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: test_TimeRE_recreation_timezone failure on systems with non-default 
posixrules
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35171>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to