classification
Title: test_imaplib failed on x86 ubuntu
Type: behavior Stage: resolved
Components: Tests Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, barry, belopolsky, ezio.melotti, kasun, r.david.murray, ysj.ray
Priority: normal Keywords:

Created on 2011-04-19 19:41 by kasun, last changed 2014-06-29 15:47 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
mk.c ezio.melotti, 2013-02-23 08:17
Messages (12)
msg134091 - (view) Author: Kasun Herath (kasun) Date: 2011-04-19 19:41
test_imaplib failed on x86 ubuntu machine with following error(s)

======================================================================
FAIL: test_Internaldate2tuple (test.test_imaplib.TestImaplib)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/kasun/workplace/cpython/Lib/test/test_imaplib.py", line 31, in test_Internaldate2tuple
    self.assertEqual(time.mktime(tt), t0)
AssertionError: 946683000.0 != 946684800

----------------------------------------------------------------------
Ran 2 tests in 0.002s

FAILED (failures=1)
test test_imaplib failed -- Traceback (most recent call last):
  File "/home/kasun/workplace/cpython/Lib/test/test_imaplib.py", line 31, in test_Internaldate2tuple
    self.assertEqual(time.mktime(tt), t0)
AssertionError: 946683000.0 != 946684800

1 test failed:
    test_imaplib
msg134112 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-04-20 00:38
This is a repeatable error?  What is your system timezone set to?  The difference is exactly one half hour.  Does the test pass if you change the calendar.timegm call to have '0' or '1' as the last element of the tuple instead of '-1'?
msg134332 - (view) Author: Kasun Herath (kasun) Date: 2011-04-24 16:07
Yes this is a repeatable error. My timezone is GMT + 5:30.

The test fails even if the last element of 'calendar.timegm's tuple is changed to 0 or 1 but pass if the function is changed as follows

print calendar.timegm((1999, 12, 31, 23, 30, 0, -1, -1, -1))
msg134376 - (view) Author: ysj.ray (ysj.ray) Date: 2011-04-25 08:17
Guess the problem is with time.mktime() and time.localtime(). Could you  debug into the Internaldate2Tuple() function and see at which step the time value(a time_struct or a float which represents seconds) is wrong?
msg134382 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-04-25 14:00
Yeah, I looked at the source of calendar.gmtime, and it turns out it ignores the isdst flag, which it also seems should be irrelevant anyway, looking at the test code again.

I tried setting my /etc/localtime to /usr/share/zoneinfo/posix/Asia/Calcutta, which gives me IST/GMT +5:30, but test_imaplib still passes for me on default.

Here is what an interpreter session looks like for me with my timezone set to IST:

>>> import calendar
>>> calendar.timegm((2000, 1, 1, 0, 0, 0, -1, -1, -1))
946684800
>>> import imaplib
>>> x = imaplib.Internaldate2tuple(b'25 (INTERNALDATE "01-Jan-2000 00:00:00 +0000")')
>>> x
time.struct_time(tm_year=2000, tm_mon=1, tm_mday=1, tm_hour=5, tm_min=30, tm_sec=0, tm_wday=5, tm_yday=1, tm_isdst=0)
>>> import time
>>> time.mktime(x)
946684800.0

Can you show us what yours looks like?  Comparing the above numbers to
yours, it appears to be your mktime that is giving the anomalous results.
msg134452 - (view) Author: Kasun Herath (kasun) Date: 2011-04-26 11:54
Yes problem seems to be with time.mktime(). Here is my output,

>>> calendar.timegm((2000, 1, 1, 0, 0, 0, -1, -1, -1))
946684800

>>> x = imaplib.Internaldate2tuple(b'25 (INTERNALDATE "01-Jan-2000 00:00:00 +0000")')

>>> x
time.struct_time(tm_year=2000, tm_mon=1, tm_mday=1, tm_hour=5, tm_min=30, tm_sec=0, tm_wday=5, tm_yday=1, tm_isdst=0)

>>> time.mktime(x)
946683000.0
msg134453 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-04-26 12:10
So this is probably not a python problem at all, but a problem with your system c library time functions. time.mktime is a thin wrapper around the mktime libc call.  Perhaps you could write a short C program to test it?  I've added Barry as nosy since he has some interest in ubuntu issues.
msg134889 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-04-30 22:17
Kasun, were you able to reproduce the problem (or show it doesn't happen) calling mktime directly from C?
msg135479 - (view) Author: Kasun Herath (kasun) Date: 2011-05-07 16:53
david, I'm not much familiar with c. Still trying to figure out how to do it
msg182725 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-02-23 08:17
I tried to reproduce the issue and copied /usr/share/zoneinfo/posix/Asia/Calcutta to /etc/localtime as suggested in msg134382, but test_imaplib passes on 2.7/3.2/3.3/3.4.

I wrote a C program to test the output of mktime:
$ cat mk.c 
#include <stdio.h>
#include <time.h>

int main() {
    struct tm buf;
    char outbuf[80];
    time_t tt;
 
    buf.tm_year = 2000-1900;
    buf.tm_mon = 1;
    buf.tm_mday = 1;
    buf.tm_hour = 5;
    buf.tm_min = 30;
    buf.tm_sec = 0;
    buf.tm_wday = 5;
    buf.tm_yday = 1;
    buf.tm_isdst = 0;

    tt = mktime(&buf);
    printf("mktime: %9.1f\n", (double)tt);
    strftime(outbuf, 80, "%c", &buf);
    printf("outbuf: %s\n", outbuf);
    return 0;
}
$ gcc -Wall -Wextra -O -ansi -pedantic mk.c -o mk
$ ./mk 
mktime: 949363200.0
outbuf: Tue Feb  1 05:30:00 2000


Kasun, can you still reproduce the failure?
If so, could you try the attached C program?
msg221840 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-29 13:18
Is there any work to be done here or can this be closed?
msg221851 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-06-29 15:47
Since we can't reproduce it and have had no response from the OP for over a year, it is indeed time to close this one.
History
Date User Action Args
2014-06-29 15:47:47r.david.murraysetstatus: open -> closed
resolution: not a bug -> works for me
messages: + msg221851
2014-06-29 13:18:58BreamoreBoysetnosy: + BreamoreBoy

messages: + msg221840
versions: + Python 3.5, - Python 3.2, Python 3.3
2013-02-23 08:17:57ezio.melottisetfiles: + mk.c
versions: + Python 3.4, - Python 3.1
nosy: + ezio.melotti

messages: + msg182725
2011-05-16 19:39:44sijinjosephsetnosy: - sijinjoseph
2011-05-11 11:39:41sijinjosephsetnosy: + sijinjoseph
2011-05-07 16:53:22kasunsetstatus: pending -> open

messages: + msg135479
2011-04-30 22:17:50r.david.murraysetstatus: open -> pending
resolution: not a bug
messages: + msg134889

stage: resolved
2011-04-26 12:10:40r.david.murraysetnosy: + barry
messages: + msg134453
2011-04-26 11:54:24kasunsetmessages: + msg134452
2011-04-25 14:00:30r.david.murraysetmessages: + msg134382
2011-04-25 08:17:46ysj.raysetnosy: + ysj.ray
messages: + msg134376
2011-04-24 16:33:38pitrousetversions: + Python 3.1, Python 2.7, Python 3.2
2011-04-24 16:07:18kasunsetmessages: + msg134332
2011-04-20 00:38:28r.david.murraysetnosy: + belopolsky
type: behavior
messages: + msg134112
2011-04-19 21:15:11pitrousetnosy: + r.david.murray
2011-04-19 19:41:53kasuncreate