[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: issue5904g.diff looks good to me. A very nice piece of work! -- ___ Python tracker ___ ___ Python-b

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Also I changed Py_DECREFs in destructor to Py_CLEAR. I understand that while not strictly required in this case, it is a good practice. -- ___ Python tracker __

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: issue5094g.diff addresses all Mark's suggestions except making struct definition public. I also made a few other changes: 1. Constructor now raises TypeError when offset is not a timedelta instead of ValueError in previous version. 2. NEWS entry no lo

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Just to add a little bit of historical perspective, this proposal is really more than seven years old: """ s.keim (Dec 20, 2002 3:33 am; Comment #13) .. do we really need methods like utcnow. I believe the following could be a little more easy to learn

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Sun, Jun 13, 2010 at 10:09 AM, Mark Dickinson wrote: .. > - Should the PyDateTime_TimeZone struct definition go into > datetime.h, so that it's avaiable if you want to export any C-API > functions later on? > The original patch had this in the header f

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: The latest patch looks good to me. I only have minor comments, in random order: - Should the PyDateTime_TimeZone struct definition go into datetime.h, so that it's avaiable if you want to export any C-API functions later on? - If you're not allowing subclass

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Attaching issue5094f.diff which implements 'UTC±HH:MM' and adds unit tests for more error cases. -- Added file: http://bugs.python.org/file17648/issue5094f.diff ___ Python tracker

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > +1 for 'UTC±HH:MM' for both tzname and __str__, too. It looks like I subconsciently allocated enough characters for this in the string buffer, so now this is a single character change. I'll do it with other changes (if any) before commit. --

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: I agree it seems fine to disallow subclassing of timezone. (And if we decide, in the light of new information, that that was wrong, then it's easy to allow subclassing later; harder to disallow it.) +1 for 'UTC±HH:MM' for both tzname and __str__, too. I'll

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I have made my mind on subclassing timezone issue. I believe subclassing should not be allowed and here is the reason: The new datetime.timezone class is a very specific implementation of tzinfo interface. It guarantees that utcoffset(dt) and friends

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: There is a separate issue #5288 asking to support sub-minute offsets. This is not hard, but the C code still has a few interfaces left from the time when offset was an integer # of minutes. I am +1 to fix that, but not as a part of this issue. On str

[issue5094] datetime lacks concrete tzinfo impl. for UTC

akira <4kir4...@gmail.com> added the comment: Minor notes: msg107186: 1. The constructor now accepts only whole number of minutes in [-23:59, 23:59] range. rfc 3339 provides the following example: 1937-01-01T12:00:27.87+00:20 This represents the same instant of time as noon, January

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am attaching a new patch, issue5094e.diff which addresses most of Mark's comments. I left out repr() because two opinions were voiced on IRC with respect to datetime. prefix. I would like to give it some more thought even though I am leaning towards

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I have to stop replying to emails. There is no reason behind roundup remove ">" comments logic. Reposting my message: """ On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson wrote: .. > Some comments from playing with this patch (without having looked a

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Fri, Jun 11, 2010 at 10:23 AM, Mark Dickinson wrote: .. > Some comments from playing with this patch (without having looked at the > implementation): > thank you very much for your comments. As we are fine-tuning the timezone class, do you think it w

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: And another minor doc issue: the docs still say: "The datetime module does not supply any concrete subclasses of tzinfo." -- ___ Python tracker __

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: One more: there's a footnote marked in the docs (line 36 of datetime.rst), but no corresponding footnote as far as I can see. -- ___ Python tracker ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: Some comments from playing with this patch (without having looked at the implementation): - As noted above, the 'timezone' class can't be subclassed. Is this deliberate? I notice that Brett said "let users subclass as needed to add DST support" in msg10700

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: I'm not sure if I missed this in the earlier discussion: is there a reason to prevent subclassing of timezone? -- ___ Python tracker ___ _

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Thanks, Daniel. This was a leftover from the previous patch. The latest patch does not actually change utcnow(). Instead the users should call datetime.now(timezone.utc). Fixed in issue5094d1.diff. -- Added file: http://bugs.python.org/file17

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Daniel Urban added the comment: In Doc/library/datetime.rst, in the documentation of datetime.utcnow this part: ".. versionchanged:: 2.7" probably should be ".. versionchanged:: 3.2". -- ___ Python tracker ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Readying the patch for commit. Added documentation, tests and implementation of fromutc() method that does not need a dst(). -- resolution: -> accepted Added file: http://bugs.python.org/file17585/issue5094d.diff __

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: Put yourself down as the maintainer of datetime in Misc/maintainers.rst and you have a deal, Alexander! =) -- ___ Python tracker ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Good catch, Daniel! Fixed in issue5094c.diff. -- Added file: http://bugs.python.org/file17570/issue5094c.diff ___ Python tracker ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Daniel Urban added the comment: Isn't it possible, that in the issue5094b.diff patch, in the new_timezone_ex function, in this part: self = (PyDateTime_TimeZone *)type->tp_alloc(type, 0); if (self == NULL) return NULL; should be a Py_DECREF(offset) call? I mean like: self = (PyDateTime_

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am attaching the next version of my patch and changing priority to high because it appears that several issues depend on resolution of this one. Here is the summary of changes since issue5094a.diff: 1. The constructor now accepts only whole number of

[issue5094] datetime lacks concrete tzinfo impl. for UTC

anatoly techtonik added the comment: On Fri, Jun 4, 2010 at 11:09 PM, Brett Cannon wrote: > Unless other people step forward to debate this we probably are not going to > reach consensus without going to python-dev to see what others think. I would really like to see: 1. a good definition of

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: On Fri, Jun 4, 2010 at 15:17, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon wrote: > .. >> For the allowable range, follow the datetime docs as someone might be >> relying on that speci

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon wrote: .. > For the allowable range, follow the datetime docs as someone might be relying > on that specification already. > Will do. I think it is as simple simple s/12/24/ in two places of the current patch

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: For the allowable range, follow the datetime docs as someone might be relying on that specification already. As for the ongoing DST debate, it seems we either need to say that since we cannot properly support all possible datetimes properly we should simply not

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Alexander Belopolsky : -- nosy: +tim_one ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > I'm still leary of supporting any form of DST. A proper DST > implementation would need to have some conditional code to > account for the datetime object passed into dst, and yet the > version you have prototyped doesn't handle it. No, any tzinfo imple

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Merging in issue7584 nosy list. -- nosy: +durban, l0nwlf, r.david.murray, techtonik ___ Python tracker ___ ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson wrote: .. > Aren't there valid timezones that are offset by more than 12 hours from UTC? Indeed, Christmas Island uses UTC+14. (http://en.wikipedia.org/wiki/Kiritimati). The most western timezone seems to b

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: I'm still leary of supporting any form of DST. A proper DST implementation would need to have some conditional code to account for the datetime object passed into dst, and yet the version you have prototyped doesn't handle it. So a proper timezone supporting DS

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > So you want a third argument that lets you flag if the timezone is DST or not? The third argument is not a flag, it is a timedelta just like the offset. I am attaching a python prototype for clarity. (See datetimeex.py.) Conceptually, a 3-argument ti

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: So you want a third argument that lets you flag if the timezone is DST or not? I still don't think that will be necessary. If people want to add that they can very easily subclass the timezone class and add support for it. This class should be focused on provid

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am having second thoughts about dst indicator. I wrote: """ 2. Do we want to add a dst indicator and altname attributes? I would say: no. I would rather treat DST as a different fixed offset timezone. """ and Brett responded: """ 2. Keep the class de

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:15 PM, Brett Cannon wrote: .. > As for the float/int argument, I personally am wary of it. Since the > timedelta constructor accepts hours as a keyword argument, I don't > see the benefit of having to support both timedeltas and i

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:41 PM, Alexander Belopolsky wrote: .. > I am not sure.   At this stage treat 12 as a placeholder for whatever > the relevant standard says. Believe it or not, at least one standard, RFC 2822, allows any offset representable as HH

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Thu, Jun 3, 2010 at 3:19 PM, Mark Dickinson wrote: .. > Aren't there valid timezones that are offset by more than 12 hours from UTC? I am not sure. At this stage treat 12 as a placeholder for whatever the relevant standard says. I've seen suggestio

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Mark Dickinson added the comment: > accept arbitrary timedelta between timedelta(hours=-12) and > timedelta(hours=12) Aren't there valid timezones that are offset by more than 12 hours from UTC? -- nosy: +mark.dickinson ___ Python tracker

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: I don't think people would get confused as to what datetime.utc was, but as you pointed out, Alexander, the module seems to like class attributes so timezone.utc is fine. As for the float/int argument, I personally am wary of it. Since the timedelta constructo

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I am attaching the next installment of the datetime.timezone class implementation. Here I add ``utc`` class attribute to timezone. I decided to place it in class rather than module namespace because this seems to be more inline with how datetime modul

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: Forgot about datetime breaking the PEP 8 rules. You're right, consistency wins. As for fixedtimezone being odd, that's why my mind went with FixedOffsetTimezone to start, but that doesn't go with the naming of the module, and fixedoffsettimezone is just hard to

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Wed, Jun 2, 2010 at 5:24 PM, Brett Cannon wrote: .. > 1. Call it FixedTimezone or something (remember it has to be CapWords). I thought consistency within module trumps PEP 8 naming standards. The datetime module (for better or worse) uses lowercase n

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: My thoughts on Alexander's questions: 1. Call it FixedTimezone or something (remember it has to be CapWords). Calling it simply Timezone does not convey the fact that DST is not supported and people might naively think it will. Its limited abilities should be p

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Here is my first attempt to implement fixed offset timezone type. The patch is based on Brett's next-patch.txt and while I changed the type name from datetime.UTC to datetime.timezone, I did not change the name of the related C structures. I would lik

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: PyPy has said over the years they plan to commit their version of datetime, they just need to get around to it. I just figured that we could use this opportunity to prepare for it. But if people want to do the C version first, that's fine as they will be the on

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Antoine Pitrou added the comment: > The second is whether we should take this opportunity to fix datetime > being a C extension module exclusively. I know PyPy has their own pure > Python version of datetime that they plan to eventually contribute. We > might as well use this as the chance to c

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: The stated long-term goal of the stdlib is to minimize the C extension modules to only those that have to be written in C (modules can still have performance enhancing extension back-ends). Since datetime does not meet that requirement it's not a matter of "if"

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I have no opinion on the first question. I would be fine with a simple "soft" deprecation where we simply add a note in documentation warning that these methods create naive datetime instances and it is preferable to use aware variants produced by meth

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: OK, it looks like we are reaching consensus here on several points: 1. Implement FixedOffsetTimezone 2. Provide a utc attribute on the datetime module that is set to ``FixedOffsetTimezone(0, "UTC")`` 3. Deprecate the various utc* methods with messages pointing o

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Brett: "[utcnow] should at least get deprecated with a message saying that people should be using ``now(utc)``" Yes, I believe all utcxxx methods of datetime are a kludge due to the lack of concrete UTC tzinfo: utcfromtimestamp() -> fromtimestamp(utc)

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: If we don't modify utcnow (and similar UTC methods) to take a flag saying to use the utc instance, then the methods should at least get deprecated with a message saying that people should be using ``now(utc)``, etc. -- _

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Note that Brett has already mentioned backward compatibility issues, but suggested that "[adding tz_aware argument may provide] a transition plan to make utcnow() always return a timezone-aware datetime object." [msg106413] I would say, lets leave utcno

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: Roundup bug bites again. Reposting via web: - On Tue, May 25, 2010 at 5:35 PM, Brett Cannon wrote: > > The singleton dislike from Antoine and me is that they are generally just not > liked in the stdlib. .. Thanks for the explanation. I realize th

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Rafe Kaplan added the comment: "Note that I am not suggesting passing anything to utcnow(). I would either leave it unchanged or make it always return aware datetime instances." FYI, all other issues aside, having utcnow() (with no parameters) return a tzaware instance will introduce backward

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: .. Thanks for the explanation. I realize that I should not have used the s-word. :-) In fact I only wanted a module level constant utc = UTC() and did not care much about other UTC class instances and whether any are permitted or easy to create. Well, t

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: The singleton dislike from Antoine and me is that they are generally just not liked in the stdlib. None/True/False are special cases because they are syntax, so having ``None is None`` ever not work would just be weird. Otherwise singletons are unnecessary in P

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan wrote: .. > I had originally thought of doing the class, and then having constants > associated with it: > >  UTC.UTC0 > > Eventually if we support multiple timezones: > >  UTC.UTC1 .. > > Well... maybe not g

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Tue, May 25, 2010 at 5:45 AM, Antoine Pitrou wrote: .. > I also agree with Brett that a singleton looks rather unnecessary (it > also look quite C++/Java-esque to me). > I still don't understand your aversion to singletons and you did not address any

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Antoine Pitrou added the comment: > Note that I am not suggesting passing anything to utcnow(). I would > either leave it unchanged or make it always return aware datetime > instances. The latter would break compatibility, though (especially given how comparison between "naive" and "aware" dat

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: > We didn't do a singleton because I don't like singletons. =) Plus they > muck with isinstance/issubclass if you don't expose the class. I am not sure what you mean by "muck with." Why would anyone want to subclass UTC? > Basically there is no need to

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: On Mon, May 24, 2010 at 11:06 PM, Rafe Kaplan wrote: .. > On 2, we had discussions about how to pass parameters in to utcnow that we > DID record.  When I > suggested it, Brett said: > >  "...using a boolean flag over an argument is much less error-prone

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: We didn't do a singleton because I don't like singletons. =) Plus they muck with isinstance/issubclass if you don't expose the class. Basically there is no need to have it be a singleton, so why bother? And Rafe is right: since utcnow() already exists, why not

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Rafe Kaplan added the comment: Alexander, about 1, that's a pretty good question. I had originally wanted to do something like that but Brett Cannon at the time thought it was not the right approach. I don't recall the details. Maybe Brett can recall. I think we had that conversation in p

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Alexander Belopolsky added the comment: I have two questions about the proposed implementation: 1. Why not follow pytz lead and expose an instance of UTC rather than the UTC class itself? 2. Is there a real need to add a boolean argument to utcnow()? I think timedelta.now(UTC()) or with utc

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Brett Cannon : Removed file: http://bugs.python.org/file13029/datetime-utc-doc.patch ___ Python tracker ___ ___ Python-bugs-list mai

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Brett Cannon : Removed file: http://bugs.python.org/file13023/datetime-utc.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: Attaching a new patch by Rafe against Python 2.7. Unfortunately with 2.7 striving for an RC next, this should only target Python 3.2 and not 2.7. -- versions: +Python 3.2 -Python 2.7, Python 3.1 Added file: http://bugs.python.org/file17455/next-patch.txt

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Alexander Belopolsky : -- nosy: +belopolsky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Éric Araujo : -- nosy: +merwok ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Brett Cannon : -- assignee: brett.cannon -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: I am currently doing a review of the patch over at http://codereview.appspot.com/22042 . ___ Python tracker ___ ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Rafe Kaplan added the comment: I thought I had uploaded this last night, apologies. Added file: http://bugs.python.org/file13029/datetime-utc-doc.patch ___ Python tracker ___ ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Walter Dörwald added the comment: The patch doesn't include any changes to the documentation. -- nosy: +doerwalter ___ Python tracker ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Brett Cannon : -- stage: test needed -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Rafe Kaplan : -- keywords: +patch Added file: http://bugs.python.org/file13023/datetime-utc.patch ___ Python tracker ___ ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Rafe Kaplan added the comment: I'm going to attempt to implement this feature. -- nosy: +rafe ___ Python tracker ___ ___ Python-bugs-l

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Brett Cannon : -- assignee: -> brett.cannon stage: needs patch -> test needed ___ Python tracker ___ ___ Python-bugs-list m

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: On Tue, Feb 3, 2009 at 03:28, STINNER Victor wrote: > > STINNER Victor 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 tes

[issue5094] datetime lacks concrete tzinfo impl. for UTC

STINNER Victor added the comment: The UTC class have to be converted to C. Can someone write a patch for datetimemodule.c (and the doc plus an unit test ;-))? -- nosy: +haypo ___ Python tracker ___

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Changes by Brett Cannon : -- priority: -> low stage: -> needs patch type: -> feature request ___ Python tracker ___ ___ Python-bugs-

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Antoine Pitrou added the comment: 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. -- nosy: +pitrou ___ Python tracker

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Gabriel Genellina added the comment: Seems perfectly reasonable to me. -- nosy: +gagenellina ___ Python tracker ___ ___ Python-bugs-li

[issue5094] datetime lacks concrete tzinfo impl. for UTC

HiroakiKawai added the comment: I want UTC tzinfo. too. -- nosy: +kawai ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Brett Cannon added the comment: On Wed, Jan 28, 2009 at 18:17, Daniel Diniz wrote: > > Daniel Diniz 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.

[issue5094] datetime lacks concrete tzinfo impl. for UTC

Daniel Diniz added the comment: 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 -- nosy: +ajaksu2 ___ Python tracker

[issue5094] datetime lacks concrete tzinfo impl. for UTC

New submission from Brett Cannon : 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