Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
stage: patch review - commit review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 88a5f2730579 by Alexander Belopolsky in branch 'default':
Issue #9527: datetime.astimezone() method will now supply a class
http://hg.python.org/cpython/rev/88a5f2730579
New changeset 336c53c1f547 by Alexander
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset a7237f157625 by Alexander Belopolsky in branch 'default':
Issue #9527: Fixes for platforms without tm_zone
http://hg.python.org/cpython/rev/a7237f157625
--
___
Python
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
Jesús Cea Avión j...@jcea.es added the comment:
This patch breaks OpenIndiana buildbots. For instance
http://www.python.org/dev/buildbot/all/builders/AMD64%20OpenIndiana%203.x/builds/3810/steps/test/logs/stdio
FAIL: test_astimezone_default_eastern (test.datetimetester.TestDateTimeTZ_Pure)
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Working on this. It turns out tm_gmtoff uses the opposite sign to
that of timezone in time.h. For more confusion, consider this:
$ TZ=EST+5 date +%z
-0500
I am rechecking all UTC offset signs.
On Fri, Jun 22, 2012 at
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 0f0e3ec22fce by Alexander Belopolsky in branch 'default':
Issue #9527: tm_gmtoff has 'correct' sign.
http://hg.python.org/cpython/rev/0f0e3ec22fce
--
___
Python tracker
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Attached patch implements astimezone() default in both Python and C.
--
stage: - patch review
Added file: http://bugs.python.org/file26062/issue9527.diff
___
Python tracker
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
On Mon, Jun 11, 2012 at 11:18 PM, James Henstridge rep...@bugs.python.org
wrote:
One problem I can see with using a fixed offset
tzinfo for localtime is that it might confuse people
when doing date arithmetic.
Yes, this
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
... is a well-defined problem which does not have an adequate solution.
I meant to say does not have an adequate solution *in the current datetime
module*. I think the enhanced datetime.astimezone() method will solve
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
This was originally posted on python-dev, but I hope reposting it here will
make this issue easier to navigate.
With addition of fixed offset timezone class and the timezone.utc
instance [0], it is easy to get UTC time as
Alexander Belopolsky alexander.belopol...@gmail.com added the comment:
Two objections have been raised to the proposed datetime.localtime() function:
1. It offers the third subtly different way to obtain current time in datetime
module. The first two being provided by datetime.now() and
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
Added file: http://bugs.python.org/file25940/testtz.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
James Henstridge ja...@jamesh.id.au added the comment:
One problem I can see with using a fixed offset tzinfo for localtime is that it
might confuse people when doing date arithmetic. For example:
d = datetime.localtime() + timedelta(days=7)
While it will give a correct answer as a
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
___
Python-bugs-list mailing
Changes by Cameron Simpson c...@zip.com.au:
--
nosy: +cameron
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
___
Python-bugs-list mailing
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset df12ce0c96eb by R David Murray in branch 'default':
#665194: Add a localtime function to email.utils.
http://hg.python.org/cpython/rev/df12ce0c96eb
--
nosy: +python-dev
Nick Coghlan ncogh...@gmail.com added the comment:
One important thing to remember is that once a time is in the past, whether or
not DST was in effect for that time *is never going to change*. That means
converting a DST aware timezone to a fixed offset timezone will work just fine
for
R. David Murray rdmur...@bitdance.com added the comment:
LocalTimezone support would be *really* helpful for the email module. It would
allow us to have unambiguous semantics for datetime objects representing
timestamps exacted from or inserted into email messages (see issue 665194 for
Changes by Miki Tebeka miki.teb...@gmail.com:
--
nosy: -tebeka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
___
Python-bugs-list
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
dependencies: +Time zone-capable variant of time.localtime
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
dependencies: +No obvious and correct way to get the time zone offset
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
I think Tim and Guido had deliberately avoided local timezone awareness when
they designed the module.
Also, I question whether the proposed API is correct. ISTM that any code that
sets the *dst* parameter is guaranteed to
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sat, Jan 29, 2011 at 11:56 PM, Raymond Hettinger
rep...@bugs.python.org wrote:
..
Also, I question whether the proposed API is correct. ISTM that any code
that sets the *dst*
parameter is guaranteed to be wrong
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Following Anatoly's review, I renamed datetime argument and a local variable,
added comments and expanded docstring. I am uploading a new patch:
datetime-localtime-proto-1.diff.
Martin, I could not figure out how to add
: Add aware local time support to datetime module - Add aware local time
support to datetime module (issue9527)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
title: Add aware local time support to datetime module (issue9527) - Add aware
local time support to datetime module
___
Python tracker rep...@bugs.python.org
http
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
___
Python-bugs-list
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Would anyone like to review this? The Rietveld link works (thanks Martin!) and
I would like to get some feedback on the python version before I invest effort
into coding this in C.
--
Changes by Guido van Rossum gu...@python.org:
--
nosy: -gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9527
___
___
Python-bugs-list
New submission from Alexander Belopolsky belopol...@users.sourceforge.net:
See python-dev post for motivation.
http://mail.python.org/pipermail/python-dev/2010-August/102842.html
I am attaching a patch implementing the proposed method in datetime.py. I will
also paste the code below. Note
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Merging nosy lists from issues #1647654 and #2736. If datetime.localtime() is
implemented, I argue that the features requested in these two issues will
become unnecessary.
--
nosy: +Neil Muller,
32 matches
Mail list logo
