[issue1667546] Time zone-capable variant of time.localtime

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker ___

[issue1667546] Time zone-capable variant of time.localtime

Roundup Robot added the comment: New changeset 3b5545ba6432 by Alexander Belopolsky in branch 'default': Issue #1667546: On platforms supporting tm_zone and tm_gmtoff fields http://hg.python.org/cpython/rev/3b5545ba6432 -- nosy: +python-dev ___ Pytho

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: On Wed, Jun 13, 2012 at 7:08 PM, Paul Boddie wrote: > I think you may have forgotten to remove docstring references to those > functions. Good catch. BTW, did you write the additional tests for strptime? This is the only thing that I want to add before

[issue1667546] Time zone-capable variant of time.localtime

Paul Boddie added the comment: On Wednesday 13 June 2012 23:51:25 Alexander Belopolsky wrote: > Alexander Belopolsky added the comment: > > I've simplified Paul's patch by removing timegm and mktimetz functions. > Also, platforms that don't support tm_zone are unaffected. I think you may have

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: I've simplified Paul's patch by removing timegm and mktimetz functions. Also, platforms that don't support tm_zone are unaffected. -- stage: patch review -> commit review Added file: http://bugs.python.org/file26002/issue1667546.diff __

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: Reopening. given the uncertainty with #9527, this issue may result in getting the TZ-aware local time support in stdlib sooner. -- resolution: duplicate -> stage: committed/rejected -> patch review status: closed -> open versions: +Python 3.3 -

[issue1667546] Time zone-capable variant of time.localtime

Changes by Alexander Belopolsky : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: On Tue, Jan 11, 2011 at 5:06 AM, anatoly techtonik wrote: .. > IIUC #9527 is about datetime and this request is about time.localtime, This is correct, but did you notice what I wrote in my last message? """ In order to properly implement #9527 in dateti

[issue1667546] Time zone-capable variant of time.localtime

anatoly techtonik added the comment: IIUC #9527 is about datetime and this request is about time.localtime, i.e. about making the API more intuitive for users. I don't think this issue should be closed. -- status: pending -> open ___ Python tracker

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: I am going to close this as superseded by #9527. In order to properly implement #9527 in datetime.py, some kind of tm_gmtoff support will need to be added to the time module, but I don't want this to become a feature that is exclusively available from

[issue1667546] Time zone-capable variant of time.localtime

Georg Brandl added the comment: (Hi Alexander, sorry for not answering on IRC, I got a phonecall and was distracted for a while.) Please take on this issue -- I've simply not had energy enough to fight it through. -- assignee: georg.brandl -> belopolsky _

[issue1667546] Time zone-capable variant of time.localtime

Alexander Belopolsky added the comment: I have updated time-4.diff patch for py3k. Code changes are minimal, mostly due to string to unicode conversion. I have not attempted to fix anything beyond passing supplied unittest, but I did noticed a few missing error return tests. I was not able

[issue1667546] Time zone-capable variant of time.localtime

Paul Boddie added the comment: Speaking for myself, I'm not sure whether I'm really the person to push this further, at least, although others may see it as a worthy sprinting topic. In principle, adding the extra fields is the right thing to do, merely because it exposes things from "struct

[issue1667546] Time zone-capable variant of time.localtime

anatoly techtonik added the comment: Yet another timezone issue. =/ Seems like it is too complicated. Should we try to organize a dedicated sprint during EuroPython? Do we need some easy to read research on the problem? Should PSF define bounty for that? Should we try to approach this with som

[issue1667546] Time zone-capable variant of time.localtime

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

[issue1667546] Time zone-capable variant of time.localtime

Changes by Alexander Belopolsky : -- stage: -> patch review type: -> feature request versions: +Python 3.2 -Python 2.7, Python 3.1 ___ Python tracker ___

[issue1667546] Time zone-capable variant of time.localtime

Georg Brandl added the comment: To be honest, I forgot about it :( ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue1667546] Time zone-capable variant of time.localtime

Antoine Pitrou added the comment: What is the status of this? -- nosy: +pitrou versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker ___ ___