Repository navigation
datetime lacks concrete tzinfo implementation for UTC #49344
Copy link
Copy link
Closed
Labels
extension-modulesC modules in the Modules dirC modules in the Modules dirtype-featureA feature request or enhancementA feature request or enhancement
Description
| BPO | 5094 |
|---|---|
| Nosy | @tim-one, @doerwalter, @brettcannon, @mdickinson, @abalkin, @pitrou, @devdanzin, @ezio-melotti, @merwok, @bitdancer, @durban, @4kir4 |
| Files |
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']Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
extension-modulesC modules in the Modules dirC modules in the Modules dirtype-featureA feature request or enhancementA feature request or enhancement
Activity
brettcannon commentedon Jan 29, 2009
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().
devdanzin commentedon Jan 29, 2009
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
brettcannon commentedon Jan 29, 2009
On Wed, Jan 28, 2009 at 18:17, Daniel Diniz <report@bugs.python.org> wrote:
I will if people are generally okay with the idea of adding this class.
kawai commentedon Jan 30, 2009
I want UTC tzinfo. too.
ggenellina commentedon Jan 31, 2009
Seems perfectly reasonable to me.
pitrou commentedon Jan 31, 2009
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.
vstinner commentedon Feb 3, 2009
The UTC class have to be converted to C. Can someone write a patch for
datetimemodule.c (and the doc plus an unit test ;-))?
brettcannon commentedon Feb 3, 2009
On Tue, Feb 3, 2009 at 03:28, STINNER Victor <report@bugs.python.org> wrote:
Yes, the example code is just an example. =)
I might have some people lined up to take this on.
rafe commentedon Feb 4, 2009
I'm going to attempt to implement this feature.
doerwalter commentedon Feb 11, 2009
The patch doesn't include any changes to the documentation.
rafe commentedon Feb 11, 2009
I thought I had uploaded this last night, apologies.
brettcannon commentedon Feb 27, 2009
I am currently doing a review of the patch over at
http://codereview.appspot.com/22042 .
71 remaining items
[-]datetime lacks concrete tzinfo impl. for UTC[/-][+]datetime lacks concrete tzinfo implementation for UTC[/+]brettcannon commentedon Jun 14, 2010
Thanks for sticking with this, Alexander. I realized I was a slight pain to deal with on this one. =)
abalkin commentedon Jun 15, 2010
Reopening to add some minor fixes to tests and documentation. See issue5094h.diff. Ezio, thanks for finding these issues.
merwok commentedon Jun 15, 2010
+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 ..."”
abalkin commentedon Jun 15, 2010
What about
"""
.. method:: datetime.utcoffset()
If :attr:`tzinfo` is ``None``, returns ``None``, else returns ...
"""
Should this use "return" too?
merwok commentedon Jun 15, 2010
.. 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.
abalkin commentedon Jun 15, 2010
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.
merwok commentedon Jun 15, 2010
Suggestion for one line:
“The dt argument must be aware with
tzinfoset toself.”“The dt argument must be an aware datetime, with
tzinfoset toself.”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.
techtonik commentedon Jun 15, 2010
Good job. Thanks for working on this.
It is possible to backport this to future of Python 2.7?
pitrou commentedon Jun 15, 2010
No.
abalkin commentedon Jun 16, 2010
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.