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')
AssertionError: '1993-04-21 09:03:00,123' != '1993-04-21 08:03:00,123'
- 1993-04-21 09:03:00,123
?             ^
+ 1993-04-21 08:03:00,123
?             ^

My local timezone is Europe/Moscow, UTC+4, no daylight saving since 2011.

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 12.04 AMD64 which handles my time zone correctly throughout.

I'm submitting a patch that allows test_logging to pass by not relying on time.timezone.

@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 Lib/test/regrtest.py test_logging
[1/1] test_logging
1 test OK.

@Juan: Since the logging test doesn't seem to be broken, I'd rather not patch it; it was at least useful for throwing up a problem. For some reason time.timezone seems to be off, and that should probably be flagged as a separate issue.

@vinay.sajip
My time.timezone is -14400. What is yours?

And datetime.datetime.now().tzinfo is always None.

@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: http://www.timeanddate.com/news/time/. As it is, the test will pass on some locations and fail on others, even if time.timezone is correct.

If time.timezone is wrong for certain locations is a separate issue that I will post as soon as I complete the unit test. I took a look at Modules/timemodule.c,and there seems to be nothing wrong there.

In short, the bug is: test_time() incorrectly uses the current time.timezone to make calculations over dates in the past.

> And datetime.datetime.now().tzinfo is always None.

I can reproduce that.

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 Caracas, it's 16200). The datetime.datetime.now().tzinfo is None, as you've both said.

I will look at this soon. Yuriy, can you confirm that with Juancarlo's patch, the test also works for you?

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, but this time no-one did :-(

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 different from the current one on the current location.

The attached patch shows that time calculations involving time.timezone may not be valid for dates different from the current one, as not even daylight-savings/summer times are taken into account, so the test may also fail depending on the time of the year it is run on.

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 slightly simpler

dt = datetime.datetime(1993, 4, 21, 8, 3, 0, 0, utc)
r.created = time.mktime(dt.astimezone(None).timetuple())

which echoes the intent of the original code to adjust for the timezone. Can you see any reason why the above shouldn't work? On my test machine, it worked fine with the above code and locations of Moscow, London and Caracas (the original code failed with Caracas, though not with Moscow - but do I understand that the original is broken).

@Vinay No reason. datetime.astimezone(None) is documented in 3.3. You may even use:

r.created = time.mktime(dt.astimezone().timetuple())

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 based.
http://hg.python.org/cpython/rev/56260d30985d