Changes by Vinay Sajip vinay_sa...@yahoo.co.uk:
--
assignee: - vinay.sajip
nosy: +vinay.sajip
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14902
___
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
@Yuriy: I set my location to Moscow (using the Gnome date widget) and ran the
test, but no failure occurs.
vinay@eta-jaunty:~/projects/python/default$ date
Tue Jul 3 15:12:39 MSD 2012
vinay@eta-jaunty:~/projects/python/default$ ./python
Yuriy Syrovetskiy c...@cblp.su added the comment:
@vinay.sajip
My time.timezone is -14400. What is yours?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14902
___
Yuriy Syrovetskiy c...@cblp.su added the comment:
And datetime.datetime.now().tzinfo is always None.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14902
___
Juancarlo Añez apal...@gmail.com added the comment:
@Vinay The test *is* broken in theory, because it uses today's time.timezone to
make calculations over a datetime in the past (1993), even when official time
zones have changes in recent years for Caracas, Moscow, and others:
Juancarlo Añez apal...@gmail.com added the comment:
And datetime.datetime.now().tzinfo is always None.
I can reproduce that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14902
___
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Sorry, I didn't quite grasp what the problem was before (timezones changing
over time). I understand better now :-)
@Yuriy: On my test machine (Ubuntu Jaunty), with Moscow set as my location, the
value of time.timezone is -10800 (for
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
BTW I just noticed that you created this issue on 24 May. Sorry I only saw it
today - in future, if you add logging issues, please add me to the nosy list,
and that way I'll pick it up sooner. Usually one of the other committers adds
me,
Juancarlo Añez apal...@gmail.com added the comment:
I did extensive testing on time.timezone, and it is correct as far as the
current date is concerned. The problem, as mentioned before, is that
test_logging is using time.timezone for dates in the past for which the time
zone may have been
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
Yes, thanks for doing the detailed analysis. I see that the original code was
trying to adjust the timezone for a past time effectively using current
timezone rules, which is why it doesn't work.
Your patch appears equivalent to the
Juancarlo Añez apal...@gmail.com added the comment:
@Vinay No reason. datetime.astimezone(None) is documented in 3.3. You may even
use:
r.created = time.mktime(dt.astimezone().timetuple())
--
___
Python tracker rep...@bugs.python.org
Changes by Juancarlo Añez apal...@gmail.com:
--
type: compile error - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14902
___
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 56260d30985d by Vinay Sajip in branch 'default':
Closes #14902: Fixed timezone conversion of a date/time in the past. Thanks to
Yuriy Syrovetskiy for the report and Juancarlo Añez for the patch on which this
fix is
Juancarlo Añez apal...@gmail.com added the comment:
My local timezone is (VET,VET) == time.tzname, and test_logging fails because
time.timezone is off by 30 minutes. I couldn't find the cause for the problem
with time.timezone, but logging is not to blame. I'm running the tests on
Ubuntu
New submission from Yuriy Syrovetskiy c...@cblp.su:
rev 152c78b94e41
test test_logging failed -- Traceback (most recent call last):
File /home/cblp/my/cpython_default/Lib/test/test_logging.py, line 2903, in
test_time
self.assertEqual(f.formatTime(r), '1993-04-21 08:03:00,123')
Yuriy Syrovetskiy c...@cblp.su added the comment:
My local timezone is Europe/Moscow, UTC+4, no daylight saving since 2011.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14902
___
16 matches
Mail list logo
