homepage

After changeset 55a3b563f0db the Gentoo buildbot is complaining.
======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 159, in test_strptime
 time.strptime(strf_output, format)
ValueError: time data 'LMT' does not match format '%Z'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
 File "/home/buildbot/buildarea/3.x.ochtman-gentoo-amd64/build/Lib/test/test_time.py", line 162, in test_strptime
 (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'LMT' input.
----------------------------------------------------------------------

New changeset 2771f7e96a52 by Florent Xicluna in branch 'default':
Add temporary tests to troubleshoot issue #13309 on Gentoo buildbot.
http://hg.python.org/cpython/rev/2771f7e96a52 

New changeset bb0ae7df08f8 by Florent Xicluna in branch 'default':
Troubleshoot issue #13309 on Gentoo buildbot.
http://hg.python.org/cpython/rev/bb0ae7df08f8 

New changeset 5b1e1967ea9d by Florent Xicluna in branch 'default':
Replace temporary tests with the real test case for issue #13309 on Gentoo.
http://hg.python.org/cpython/rev/5b1e1967ea9d 

"""
import time
import sys
t = time.gmtime(time.time())
s = time.strftime('%Z', t)
print(s)
time.mktime((-1, 1, 1, 0, 0, 0, -1, -1, -1))
t = time.gmtime(time.time())
s = time.strftime('%Z', t)
print(s)
"""
outputs:
SAST
LMT
on my Gentoo box. I'm still figuring out why...

It seems that "mktime" is buggy on Gentoo.
You can try to reset its state in some way before to retry strftime:
t = time.gmtime(time.time())
s = time.strftime('%Z', t)
print(s)
time.mktime((-1, 1, 1, 0, 0, 0, -1, -1, -1))
s = time.strftime('%Z', t)
print(s)
time.mktime((1, 1, 1, 0, 0, 0, 0, 0, -1))
s = time.strftime('%Z', t)
print(s)
I guess it could output:
SAST
LMT
SAST

It outputs:
SAST
LMT
LMT
An equivalent C program to the first test:
"""
#include <time.h>
#include <stdlib.h>
#include <stdio.h>
int main() {
 time_t t;
 struct tm *tmp;
 t = time(NULL);
 tmp = localtime(&t);
 char str[200];
 strftime(str, sizeof(str), "%Z", tmp);
 puts(str);
 struct tm tmp2;
 tmp2.tm_sec = 0;
 tmp2.tm_min = 0;
 tmp2.tm_hour = 0;
 tmp2.tm_mday = 1;
 tmp2.tm_mon = 1;
 tmp2.tm_year = -1;
 tmp2.tm_wday = -1;
 tmp2.tm_yday = -1;
 tmp2.tm_isdst = -1;
 mktime(&tmp2);
 t = time(NULL);
 tmp = localtime(&t);
 strftime(str, sizeof(str), "%Z", tmp);
 puts(str);
 return 0;
}
"""
Outputs (as expected):
SAST
SAST
Perhaps it's not mktime?

See also issue #13313 on timezone, seen on x86 FreeBSD 7.2

It's not just Gentoo. I get this error repeatably on Ubuntu Oneiric 64- bit and Linux Mint Katya 64-bit, though not on the 32-bit variants.

I also get this error on Mageia. If this can't be fixed, the test should be skipped or removed.

LMT stands for Local Mean Time.
I found a report of someone having an issue parsing timezone with Python 2.6. Looks quite similar.
http://www.aczoom.com/forums/blockhosts/mar-10-151801-domains-blockhosts5599-error-failed-to-parse-date-for-ip-18911419951 

It is definitely a glibc issue. Here's a C snippet to reproduce:
"""
#include <time.h>
#include <stdlib.h>
int main() {
 time_t t;
 struct tm tmp;
 char str[200];
 t = time(NULL);
 tmp = *gmtime(&t);
 tmp.tm_gmtoff = 0;
 tmp.tm_zone = NULL;
 strftime(str, sizeof(str), "%Z", &tmp);
 puts(str);
 t = -2461446500;
 localtime(&t);
 t = time(NULL);
 tmp = *gmtime(&t);
 tmp.tm_gmtoff = 0;
 tmp.tm_zone = NULL;
 strftime(str, sizeof(str), "%Z", &tmp);
 puts(str);
 return 0;
}
"""
Output:
CET
PMT
Calling localtime() or mktime() with a time largely in the past seems to corrupt the glibc's internal time structures (the "char *tm_zone[]").

New changeset 05164831011e by Antoine Pitrou in branch 'default':
Avoid a glibc bug in test_time (issue #13309)
http://hg.python.org/cpython/rev/05164831011e 

Has it been reported?

> Has it been reported?
Yes, in http://sourceware.org/bugzilla/show_bug.cgi?id=13401 

New changeset bcd347cd6bf2 by Florent Xicluna in branch 'default':
Use unittest.skipUnless to skip the test related to the glibc bug, issue #13309.
http://hg.python.org/cpython/rev/bcd347cd6bf2 

Thank you for the investigation, and the bug report to the glibc team.
I propose to close it as "won't fix".