Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wrong time.timezone #66988

Closed
4kir4 mannequin opened this issue Nov 5, 2014 · 7 comments
Closed

wrong time.timezone #66988

4kir4 mannequin opened this issue Nov 5, 2014 · 7 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@4kir4
Copy link
Mannequin

4kir4 mannequin commented Nov 5, 2014

BPO 22799
Nosy @abalkin, @4kir4
Superseder
  • bpo-28157: Document time module constants (timezone, tzname, etc.) as deprecated.
  • 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 2016-09-14.19:08:31.361>
    created_at = <Date 2014-11-05.15:00:06.276>
    labels = ['type-bug', 'library']
    title = 'wrong time.timezone'
    updated_at = <Date 2016-09-14.19:17:21.797>
    user = 'https://github.com/4kir4'

    bugs.python.org fields:

    activity = <Date 2016-09-14.19:17:21.797>
    actor = 'belopolsky'
    assignee = 'none'
    closed = True
    closed_date = <Date 2016-09-14.19:08:31.361>
    closer = 'belopolsky'
    components = ['Library (Lib)']
    creation = <Date 2014-11-05.15:00:06.276>
    creator = 'akira'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 22799
    keywords = []
    message_count = 7.0
    messages = ['230684', '231754', '234893', '234901', '234905', '234907', '276476']
    nosy_count = 2.0
    nosy_names = ['belopolsky', 'akira']
    pr_nums = []
    priority = 'normal'
    resolution = 'wont fix'
    stage = None
    status = 'closed'
    superseder = '28157'
    type = 'behavior'
    url = 'https://bugs.python.org/issue22799'
    versions = ['Python 3.4', 'Python 3.5', 'Python 3.6']

    @4kir4
    Copy link
    Mannequin Author

    4kir4 mannequin commented Nov 5, 2014

    $ TZ=:Europe/Moscow ./python -mtest -v test_time
      

    ======================================================================
    FAIL: test_localtime_timezone (test.test_time.TestPytime)
    ----------------------------------------------------------------------

      Traceback (most recent call last):
        File ".../Lib/test/test_time.py", line 721, in test_localtime_timezone
          self.assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst])
      AssertionError: 10800 != 14400
      
      

    Ran 45 tests in 1.832s

    FAILED (failures=1, skipped=3)
    test test_time failed
    1 test failed:
    test_time

    UTC offset had changed on 2014-10-26 in Europe/Moscow timezone from
    MSK+0400 to MSK+0300.

    Python time.timezone returns -14400 (old utc offset) despite C timezone
    variable having the correct value (Python uses tm_gmtoff from Jan here).

    Similar case where timezone, altzone may be wrong
    http://bugs.python.org/msg31138

    The issue again http://bugs.python.org/issue22798 is that time timezone
    attribute is out-of-sync with the corresponding C variable i.e., C
    library provides correct values but time module doesn't use them.

    @4kir4 4kir4 mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Nov 5, 2014
    @4kir4
    Copy link
    Mannequin Author

    4kir4 mannequin commented Nov 27, 2014

    This issue could be fixed using sync-time-timezone-attr-with-c.diff patch from http://bugs.python.org/issue22798

    @abalkin
    Copy link
    Member

    abalkin commented Jan 28, 2015

    Isn't this a duplicate of bpo-13466?

    @4kir4
    Copy link
    Mannequin Author

    4kir4 mannequin commented Jan 28, 2015

    Isn't this a duplicate of bpo-13466?

    In what way is it a duplicate?

    @abalkin
    Copy link
    Member

    abalkin commented Jan 28, 2015

    Please take a look at msg148208. I agree with MAL that time module globals timezone and daylight should be deprecated in favor of tm_gmtoff or datetime.astimezone().

    @4kir4
    Copy link
    Mannequin Author

    4kir4 mannequin commented Jan 28, 2015

    I agree that time.timezone, time.altzone is not enough in the general
    case. Because UTC offset may be different at different dates for
    reasons unrelated to DST transitions therefore any solution that
    doesn't take into account a given date/time into account will fail.

    *Nothing* works in the general case. Nothing.

    But it doesn't mean that the current behaviour of time.timezone
    can't be improved for this particular use-case:

      lt = time.localtime() # in a short-lived script
      assertEqual(lt.tm_gmtoff, -[time.timezone, time.altzone][lt.tm_isdst])

    The test checks values for the current time (time.localtime()).
    It should work in *most* cases if time.timezone/altzone have correct
    values at import time.

    Perhaps synchronizing time.timezone with C timezone variable as I've
    mentioned before http://bugs.python.org/issue22798 may fix this issue
    too.

    @abalkin
    Copy link
    Member

    abalkin commented Sep 14, 2016

    Closing. See bpo-22798 for the reasons why synchronizing C variables with the time module constants is not a solution.

    @abalkin abalkin closed this as completed Sep 14, 2016
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant