well, I think, I have found this bug on time.mktime() for dates less
than 1976-09-26

when I do stringtotime of 1976-09-25 

print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) 

extract date = 1976 9 25
extract time = 0 0 0
timeint 212454000
and 
timetostring(212454000) = 1976-09-24T23:00:00Z !? 

To be honest the date that kept me the action was the 1-1-1970 that
appears 31-12-1969. After timetostring(stringtotime(date)))

I made the test and time.mktime got a bug when date is less than
1976-09-26 
see:
for 1976-09-27T00:00:00Z time.mktime gives 212630400
for 1976-09-26T00:00:00Z time.mktime gives 212544000
for 1976-09-25T00:00:00Z time.mktime gives 212454000

212630400 - 212544000 = 86400 (seconds) , one day correct !
but
212544000 - 212454000 = 90000 (seconds), one day more 3600 (seconds),
more one hour ?!? 
    
--
Sérgio M. B. 

This appears to be a timezone/DST issue:
on Sept. 26, 1976 Daylight Saving Time ended at least in the European Union.

I can't reproduce this problem. On my system (OSX), I get

>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

What system are you using? What Python version? What timezone are you in?

python-2.4.4-1.fc6
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

Looks like an FC6 bug to me (either in their C library, or in their Python port). On Debian 3.1, Python 2.4.1, I also get 86400.0. Please report this to Redhat; I'm closing this as "works for me". If you stil think there is a bug in Python, please point to the exact source that you think is erroneous, and the change that should be made.

here with ubuntu 6.10 with python 2.4.4c1 
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0

here with ubuntu 5.16 with python 2.4.2
kernel-2.6.12
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

on my FC6 same 
first time 
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
second and third time 
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

Very strange !
>>> import time
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212544000.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
90000.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0
>>> time.mktime((1976,9,26,0,0,0,0,0,0))
212540400.0

Please take a look at the implementation of mktime, and reformulate it as a C program. This should demonstrate you that the bug is not in Python, but in the C library.

Also please respond to the question what timezone you are in.

Also, don't change the priority of bugs.

I have the smae problem.

My system info is:
Python 2.4.3 (#1, Oct 18 2006, 16:42:32)
[GCC 4.1.1 (Gentoo 4.1.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.


my libc version is 2.4-r4.

I'll try to run the analogous program in C and see whether this is a bug of libc and not python.

More info later on.

timezone :  WET in winter WEST in summer 
I try same with timezone of NEW YORK and 
>>> time.mktime((1976,9,26,0,0,0,0,0,0))-time.mktime((1976,9,25,0,0,0,0,0,0))
86400.0

OK. This is almost surely NOT a Python bug but most likely a libc bug.

In c:
----------
#include <time.h>
#include <stdio.h>

int main(int argc, char* argv[]){
        struct tm t1;
        struct tm t2;

        /* midnight 26/SET/1076*/
        t1.tm_sec  = 0;
        t1.tm_min  = 0;
        t1.tm_hour = 0;
        t1.tm_mday = 26;
        t1.tm_mon  = 8;
        t1.tm_year = 76;

        /* midnight 25/SET/1076*/
        t2.tm_sec  = 0;
        t2.tm_min  = 0;
        t2.tm_hour = 0;
        t2.tm_mday = 25;
        t2.tm_mon  = 8;
        t2.tm_year = 76;

        printf("%li\n", mktime(&t1)-mktime(&t2));
        printf("%li\n", mktime(&t1)-mktime(&t2));

        return 0;
}
------
Outputs:

90000
86400


In perl:
-----
perl -le 'use POSIX; $t1=POSIX::mktime(0,0,0,26,8,76) -POSIX::mktime(0,0,0,25,8,76); $t2 = POSIX::mktime(0,0,0,26,8,76) -POSIX::mktime(0,0,0,25,8,76) ; print $t1."\n". $t2'
-----

Outputs

90000
86400

-----

My system is gentoo with glibc 2.4-r4
and my timezone is:
/usr/share/zoneinfo/Europe/Lisbon

When I changed this to another timezone (Say London) the problem didn't exist.

Thank you all for your time.

ok bug openned on 
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4033

cvalente, thanks for the research. Making a second attempt at closing this as third-party bug.

well I found the bug is in ./site-packages/_xmlplus/utils/iso8601.py

 gmt = __extract_date(m) + __extract_time(m) + (0, 0, 0) this is wrong 
My sugestion is:  
 gmt = __extract_date(m) + __extract_time(m)
 gmt = datetime(gmt).timetuple()

(0,0,0) zero for week of day, zero for day of the year and zero isdst is the error here. 

timetuple calculate this last 3 numbers well. 
and my problem is gone !

references http://docs.python.org/lib/module-time.html: 
0  	tm_year  	(for example, 1993)
1 	tm_mon 	        range [1,12]
2 	tm_mday 	range [1,31]
3 	tm_hour 	range [0,23]
4 	tm_min 	        range [0,59]
5 	tm_sec 	        range [0,61]; see (1) in strftime() description
6 	tm_wday 	range [0,6], Monday is 0
7 	tm_yday 	range [1,366]
8 	tm_isdst 	0, 1 or -1; see below

please forget my last comment, it is all wrong