Skip to content

time.utcoffset() #51911

Closed
Closed

Description

@techtonik
mannequin
BPO 7662
Nosy @abalkin, @pitrou, @merwok
Superseder
  • bpo-9527: Add aware local time support to datetime module
  • 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 = 'https://github.com/abalkin'
    closed_at = <Date 2011-01-14.00:18:42.382>
    created_at = <Date 2010-01-09.17:15:39.926>
    labels = ['type-feature', 'library']
    title = 'time.utcoffset()'
    updated_at = <Date 2011-01-14.04:25:28.522>
    user = 'https://bugs.python.org/techtonik'

    bugs.python.org fields:

    activity = <Date 2011-01-14.04:25:28.522>
    actor = 'belopolsky'
    assignee = 'belopolsky'
    closed = True
    closed_date = <Date 2011-01-14.00:18:42.382>
    closer = 'techtonik'
    components = ['Library (Lib)']
    creation = <Date 2010-01-09.17:15:39.926>
    creator = 'techtonik'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 7662
    keywords = []
    message_count = 11.0
    messages = ['97463', '97472', '97509', '99119', '99120', '107172', '126064', '126217', '126218', '126220', '126224']
    nosy_count = 3.0
    nosy_names = ['belopolsky', 'pitrou', 'eric.araujo']
    pr_nums = []
    priority = 'normal'
    resolution = 'rejected'
    stage = 'resolved'
    status = 'closed'
    superseder = '9527'
    type = 'enhancement'
    url = 'https://bugs.python.org/issue7662'
    versions = ['Python 3.3']

    Activity

    1. techtonik commented on Jan 9, 2010

      techtonikmannequin
      MannequinAuthor

      The proposal to add the function that will allow to get current UTC offset. Do we need a PEP for this one?

      def time.utcoffset():
      """Return current UTC offset in seconds"""
      return -(time.altzone if time.daylight else time.timezone)

    2. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Jan 9, 2010
    3. changed the title [-]time.utcoffset(dst=true)[/-] [+]time.utcoffset()[/+] on Jan 9, 2010
    4. briancurtin commented on Jan 9, 2010

      @briancurtin
      Member

      I think this would be nice, but see msg97471 from your diff.py ISO timestamp issue. time.daylight should probably be time.localtime().tm_isdst.

    5. techtonik commented on Jan 10, 2010

      techtonikmannequin
      MannequinAuthor

      Answered in msg97503

      In the meanwhile it looks like another proposal about RFC format in issue bpo-7584 doesn't account for proper timezone too.

    6. techtonik commented on Feb 9, 2010

      techtonikmannequin
      MannequinAuthor

      Updated Python code according to discussion from aforementioned issue bpo-7582. Unfortunately, I can't find Python source for time module to make a proper patch out of it.

      def time.utcoffset():
      """Return current UTC offset in seconds"""
      isdst = time.localtime().tm_isdst
      if (time.daylight and isdst):
      return -time.altzone
      else:
      return -time.timezone

    7. pitrou commented on Feb 9, 2010

      @pitrou
      Member

      The time module is written in C, in Modules/timemodule.c.
      If this is too bothersome to write in C, the function could perhaps be added to the datetime module instead.
      In any case, we need a proper patch, including unit tests if possible.

      (and I agree that anything making the time stuff easier to use is welcome)

    8. abalkin commented on Jun 6, 2010

      @abalkin
      Member

      I would prefer exposing tm_gmtoff in time.localtime() output. The advantage is that on platforms that support it is struct tm, it will return correct offset for times in the past, not only for the current time. See bpo-1647654.

      On platforms without tm_gmtoff we can fill it with -tm_isdst?timezone:altzone. The current situation on Linux is just backwards: we are trying to divine altzone by sampling tm_gmtoff and throw tm_gmtoff away.

      See http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edge-case/.

    9. self-assigned this
      on Jun 6, 2010
    10. abalkin commented on Jan 12, 2011

      @abalkin
      Member

      I am going to close this as superseded by bpo-9527. All these issues, current, bpo-9527, and bpo-1647654 are really about Python's lack of access to the system timezone information and bpo-9527 seem to be the most appropriate solution.

      My specific concern about proposed time.utcoffset() is that you normally need UTC offset together with current time, but localtime() call followed by utcoffset() may lead to a race condition.

    11. techtonik commented on Jan 13, 2011

      techtonikmannequin
      MannequinAuthor

      This one is a different issue. Even though it can not be solved without by bpo-9527, it is not superseded by it. So, better add to dependencies.

    12. brettcannon commented on Jan 13, 2011

      @brettcannon
      Member

      You can discuss within the comments whether this issue should be re-opened or not, but do not take it upon yourself to change the status on your own once a core developer has already closed an issue as their decision supersedes that of a regular user.

    13. techtonik commented on Jan 14, 2011

      techtonikmannequin
      MannequinAuthor

      I am tired. Do as you wish.

    14. abalkin commented on Jan 14, 2011

      @abalkin
      Member

      Just to clarify: Anatoly changed the resolution, not status (and I agree that was not appropriate.) The status was set to "pending" and that would change to "open" automatically if a new comment is posted.

      As for the substance of Anatoly's objection - I agree that this proposal is different from bpo-9527. That is why I set resolution to "rejected" rathe than "duplicate". This issue can probably be properly classified as a duplicate of bpo-1647654, but I consider bpo-9527 the most promising solution to the problem of finding the system timezone offset.

    15. 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

    Labels

    stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions