homepage

I'm getting this failure in test_email (Windows 64-bit build):
====================================================================== 
ERROR: test_localtime_epoch_notz_daylight_false (test_utils.LocaltimeTests) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
 File "C:\Users\stefan\pydev\cpython\lib\test\test_email\test_utils.py", line 112, in test_localtime_epoch_notz_dayl
ight_false 
 t1 = utils.localtime(t0) 
 File "C:\Users\stefan\pydev\cpython\lib\email\utils.py", line 397, in localtime 
 seconds = time.mktime(tm) 
OverflowError: mktime argument out of range 
 
====================================================================== 
ERROR: test_localtime_epoch_notz_daylight_true (test_utils.LocaltimeTests) 
---------------------------------------------------------------------- 
Traceback (most recent call last): 
 File "C:\Users\stefan\pydev\cpython\lib\test\test_email\test_utils.py", line 105, in test_localtime_epoch_notz_dayl
ight_true 
 t1 = utils.localtime(t0) 
 File "C:\Users\stefan\pydev\cpython\lib\email\utils.py", line 397, in localtime 
 seconds = time.mktime(tm) 
OverflowError: mktime argument out of range

Same here with VS 2008.

I haven't touched localtime since pycon, so I presume this hasn't been detected before due to our lack of a windows 64bit buildbot.

I don't have a Win 64 setup, but I think replacing 1970 with say 1990 in the tests should fix the problem.

I am surprised that we don't see the same failure on 32-bit windows buildbot. Windows mktime does not support negative time_t in either 32 or 64 bit version:
http://msdn.microsoft.com/en-us/library/d1y53h2a(v=vs.110).aspx
We are probably just lucky and no Windows buildbot uses a TZ set ahead of UTC. Stefan, what is your timezone?
What is happening here is that mktime() is called for 1970年01月01日 00:00 which results in positive timestamp for the timezones west of Greenwich and negative timestamp east of Greenwich. For example, using GNU date:
$ TZ=Europe/Paris date -d "1970-01-01 00:00" +%s
-3600
$ TZ=America/New_York date -d "1970-01-01 00:00" +%s
18000
I am adding Victor as an expert on pushing the limits of date/time functions.

My timezone is CET, so that fits your explanation. Indeed, the failure
also occurs on Windows 32-bit.

Is this something that has to be fixed during the freeze? The fix is trivial: s/1970/1990/g, but I planned to revisit TZ-dependent tests during the beta period. I think we don't use run_with_tz() enough. It would also be great to make it work on windows.

New changeset 367e376e5ba2 by Victor Stinner in branch '3.3':
Close #15165: Fix test_email on Windows 64 bits
http://hg.python.org/cpython/rev/367e376e5ba2
New changeset 651e8613e579 by Victor Stinner in branch 'default':
(Merge 3.3) Close #15165: Fix test_email on Windows 64 bits
http://hg.python.org/cpython/rev/651e8613e579 

This issue is not related to the email module, but it is a Windows limitation: datetime.datetime(1970, 1, 1).timestamp() raises a same OverflowError.