Skip to content

test_TimeRE_recreation_timezone failure on systems with non-default posixrules #79352

Closed

Description

@izbyshev
mannequin
BPO 35171
Nosy @vstinner, @benjaminp, @serhiy-storchaka, @pganssle, @izbyshev, @miss-islington
PRs
  • bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems #10347
  • [3.7] closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347) #10357
  • [3.6] closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347) #10358
  • [2.7] closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347) #10359
  • 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 2018-11-06.04:29:11.944>
    created_at = <Date 2018-11-05.22:53:29.646>
    labels = ['3.7', '3.8', 'type-bug', 'tests']
    title = 'test_TimeRE_recreation_timezone failure on systems with non-default posixrules'
    updated_at = <Date 2018-11-06.04:59:10.218>
    user = 'https://github.com/izbyshev'

    bugs.python.org fields:

    activity = <Date 2018-11-06.04:59:10.218>
    actor = 'miss-islington'
    assignee = 'none'
    closed = True
    closed_date = <Date 2018-11-06.04:29:11.944>
    closer = 'benjamin.peterson'
    components = ['Tests']
    creation = <Date 2018-11-05.22:53:29.646>
    creator = 'izbyshev'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 35171
    keywords = ['patch']
    message_count = 5.0
    messages = ['329320', '329338', '329340', '329341', '329342']
    nosy_count = 6.0
    nosy_names = ['vstinner', 'benjamin.peterson', 'serhiy.storchaka', 'p-ganssle', 'izbyshev', 'miss-islington']
    pr_nums = ['10347', '10357', '10358', '10359']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue35171'
    versions = ['Python 2.7', 'Python 3.6', 'Python 3.7', 'Python 3.8']

    Activity

    1. izbyshev commented on Nov 5, 2018

      izbyshevmannequin
      MannequinAuthor

      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 (

      get_zone(julyname, 9, &p);
      ), 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

    2. added
      testsTests in the Lib/test dir
      type-bugAn unexpected behavior, bug, or error
      on Nov 5, 2018
    3. benjaminp commented on Nov 6, 2018

      @benjaminp
      Contributor

      New changeset f1b9ad3 by Benjamin Peterson (Alexey Izbyshev) in branch 'master':
      closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347)
      f1b9ad3

    4. miss-islington commented on Nov 6, 2018

      @miss-islington
      Contributor

      New changeset ca592bc by Miss Islington (bot) in branch '3.7':
      closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347)
      ca592bc

    5. miss-islington commented on Nov 6, 2018

      @miss-islington
      Contributor

      New changeset d0e3105 by Miss Islington (bot) in branch '3.6':
      closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347)
      d0e3105

    6. miss-islington commented on Nov 6, 2018

      @miss-islington
      Contributor

      New changeset ffbce43 by Miss Islington (bot) in branch '2.7':
      closes bpo-35171: Fix test_TimeRE_recreation_timezone failure on some systems. (GH-10347)
      ffbce43

    7. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      3.7 (EOL)end of life3.8 (EOL)end of lifetestsTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or error

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions