Skip to content

datetime lacks concrete tzinfo implementation for UTC #49344

Closed

Description

@brettcannon
BPO 5094
Nosy @tim-one, @doerwalter, @brettcannon, @mdickinson, @abalkin, @pitrou, @devdanzin, @ezio-melotti, @merwok, @bitdancer, @durban, @4kir4
Files
  • next-patch.txt: against 2.7
  • issue5094.diff
  • issue5094a.diff
  • localtime.py: aware local time implementation
  • datetimeex.py: Python prototype for 3-argument timezone
  • issue5094b.diff
  • issue5094c.diff
  • issue5094d.diff
  • issue5094d1.diff: Fixed utcnow() documentation. No code change from issue5094d.diff.
  • issue5094e.diff
  • issue5094f.diff: 'UTC±HH:MM' and more unit tests
  • issue5094g.diff
  • issue5094h.diff
  • 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 2010-06-16.02:02:27.617>
    created_at = <Date 2009-01-29.00:52:42.326>
    labels = ['extension-modules', 'type-feature']
    title = 'datetime lacks concrete tzinfo implementation for UTC'
    updated_at = <Date 2010-07-10.21:35:17.148>
    user = 'https://github.com/brettcannon'

    bugs.python.org fields:

    activity = <Date 2010-07-10.21:35:17.148>
    actor = 'eric.araujo'
    assignee = 'belopolsky'
    closed = True
    closed_date = <Date 2010-06-16.02:02:27.617>
    closer = 'belopolsky'
    components = ['Extension Modules']
    creation = <Date 2009-01-29.00:52:42.326>
    creator = 'brett.cannon'
    dependencies = []
    files = ['17455', '17525', '17533', '17541', '17544', '17569', '17570', '17585', '17586', '17631', '17648', '17657', '17680']
    hgrepos = []
    issue_num = 5094
    keywords = ['patch']
    message_count = 91.0
    messages = ['80735', '80740', '80745', '80807', '80857', '80866', '81043', '81086', '81119', '81641', '81649', '82818', '106403', '106411', '106412', '106413', '106414', '106415', '106422', '106445', '106476', '106478', '106483', '106484', '106485', '106487', '106490', '106493', '106494', '106496', '106498', '106518', '106565', '106911', '106914', '106920', '106923', '106971', '106973', '106974', '106976', '106977', '106980', '106997', '106998', '107006', '107008', '107059', '107060', '107072', '107092', '107105', '107107', '107158', '107186', '107189', '107190', '107212', '107279', '107290', '107291', '107545', '107546', '107547', '107548', '107552', '107554', '107569', '107608', '107628', '107668', '107670', '107676', '107683', '107733', '107737', '107738', '107742', '107743', '107786', '107787', '107819', '107874', '107886', '107889', '107890', '107891', '107892', '107893', '107894', '107901']
    nosy_count = 17.0
    nosy_names = ['tim.peters', 'doerwalter', 'brett.cannon', 'mark.dickinson', 'belopolsky', 'ggenellina', 'pitrou', 'techtonik', 'ajaksu2', 'kawai', 'ezio.melotti', 'eric.araujo', 'r.david.murray', 'rafe', 'daniel.urban', 'l0nwlf', 'akira']
    pr_nums = []
    priority = 'high'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue5094'
    versions = ['Python 3.2']

    Activity

    1. brettcannon commented on Jan 29, 2009

      @brettcannon
      MemberAuthor

      When you call datetime.datetime.utcnow() you get back a naive datetime
      object. But why? You asked for UTC as the timezone based on what method
      call you made. And UTC is a very concrete timezone that never changes.

      It would be nice to have a concrete UTC tzinfo class that utcnow() uses
      so that at least those datetime instances are non-naive.

      If people have no issues with making this happen I will write the code
      for the concrete UTC tzinfo instance and make the appropriate changes to
      utcnow().

    2. devdanzin commented on Jan 29, 2009

      devdanzinmannequin
      Mannequin

      Brett,
      It might be worth to update tzinfo-examples.py to use your concrete UTC
      then:

      http://svn.python.org/view/python/trunk/Doc/includes/tzinfo-examples.py?rev=62214&view=markup

    3. brettcannon commented on Jan 29, 2009

      @brettcannon
      MemberAuthor

      On Wed, Jan 28, 2009 at 18:17, Daniel Diniz <report@bugs.python.org> wrote:

      Daniel Diniz <ajaksu@gmail.com> added the comment:

      Brett,
      It might be worth to update tzinfo-examples.py to use your concrete UTC
      then:

      I will if people are generally okay with the idea of adding this class.

    4. kawai commented on Jan 30, 2009

      kawaimannequin
      Mannequin

      I want UTC tzinfo. too.

    5. ggenellina commented on Jan 31, 2009

      ggenellinamannequin
      Mannequin

      Seems perfectly reasonable to me.

    6. pitrou commented on Jan 31, 2009

      @pitrou
      Member

      Please do. The current situation where the doc tells you not to use
      "naive" datetime objects but Python gives you no way to do so is awful.

    7. vstinner commented on Feb 3, 2009

      @vstinner
      Member

      The UTC class have to be converted to C. Can someone write a patch for
      datetimemodule.c (and the doc plus an unit test ;-))?

    8. brettcannon commented on Feb 3, 2009

      @brettcannon
      MemberAuthor

      On Tue, Feb 3, 2009 at 03:28, STINNER Victor <report@bugs.python.org> wrote:

      STINNER Victor <victor.stinner@haypocalc.com> added the comment:

      The UTC class have to be converted to C.

      Yes, the example code is just an example. =)

      Can someone write a patch for
      datetimemodule.c (and the doc plus an unit test ;-))?

      I might have some people lined up to take this on.

    9. self-assigned this
      on Feb 3, 2009
    10. rafe commented on Feb 4, 2009

      rafemannequin
      Mannequin

      I'm going to attempt to implement this feature.

    11. doerwalter commented on Feb 11, 2009

      @doerwalter
      Contributor

      The patch doesn't include any changes to the documentation.

    12. rafe commented on Feb 11, 2009

      rafemannequin
      Mannequin

      I thought I had uploaded this last night, apologies.

    13. brettcannon commented on Feb 27, 2009

      @brettcannon
      MemberAuthor

      I am currently doing a review of the patch over at
      http://codereview.appspot.com/22042 .

    14. 71 remaining items

    15. changed the title [-]datetime lacks concrete tzinfo impl. for UTC[/-] [+]datetime lacks concrete tzinfo implementation for UTC[/+] on Jun 14, 2010
    16. brettcannon commented on Jun 14, 2010

      @brettcannon
      MemberAuthor

      Thanks for sticking with this, Alexander. I realized I was a slight pain to deal with on this one. =)

    17. abalkin commented on Jun 15, 2010

      @abalkin
      Member

      Reopening to add some minor fixes to tests and documentation. See issue5094h.diff. Ezio, thanks for finding these issues.

    18. merwok commented on Jun 15, 2010

      @merwok
      Member

      +1 for replacing math range notation with English. Much easier for non-math people that do Python :)

      One more nit: Your docstrings use verb forms like “Returns” where PEP 257 advises to use “Return”: “[the docstring] prescribes the function or method's effect as a command ("Do this", "Return that"), not as a description; e.g. don't write "Returns the pathname ..."”

    19. abalkin commented on Jun 15, 2010

      @abalkin
      Member

      What about

      """
      .. method:: datetime.utcoffset()

      If :attr:`tzinfo` is ``None``, returns ``None``, else returns ...
      """

      Should this use "return" too?

    20. merwok commented on Jun 15, 2010

      @merwok
      Member

      .. method:: datetime.utcoffset()

      Return ``None`` if :attr:`tzinfo` is ``None``, else else return ...

      That said, to keep diffs readable, perhaps stick with the existing
      convention know, and later a PEP-257 compliance diff can be made.

    21. abalkin commented on Jun 15, 2010

      @abalkin
      Member

      How to specify offset range horse got its beating above. See msg107554. The current wording is the best compromise between verbosity and precision.

      Replacing the patch with one that fixes other nits.

    22. merwok commented on Jun 15, 2010

      @merwok
      Member

      Suggestion for one line:
      “The dt argument must be aware with tzinfo set to self.”
      “The dt argument must be an aware datetime, with tzinfo set to self.”

      If there is a reST construct for aware datetime, use it. Since “self” is not special, perhaps an alternate wording like “the timezone instance from which the method is called”, but less ugly.

      Some PyDoc_STR calls still use “Returns.”

      By the way, you could have committed the unittest changes directly.

    23. techtonik commented on Jun 15, 2010

      techtonikmannequin
      Mannequin

      Good job. Thanks for working on this.

      It is possible to backport this to future of Python 2.7?

    24. pitrou commented on Jun 15, 2010

      @pitrou
      Member

      It is possible to backport this to future of Python 2.7?

      No.

    25. abalkin commented on Jun 16, 2010

      @abalkin
      Member

      On this happy note, I am closing this issue. Doc changes have been committed in r82004, test changes in r82003. For repr(timezone(..)) development, please follow issue bpo-9000.

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

    extension-modulesC modules in the Modules dirtype-featureA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions