The problem:
time.mktime(time.gmtime(0)) - time.timezone == -3600.
0
(Should be 0.0 if I understood it right)

Python seems to miscalculate the local time when using 
mktime. The problem appeared when one of the runtests 
in MoinMoin failed (spefically MoinMoin._tests.
test_parser_wiki.WikiMacroTestCase)

I used two machines for testing:
1. NetBSD 1.6.1 (GENERIC), Python version 2.3.3 (#1, 
Feb 20 2004, 00:53:29) [GCC 2.95.3 20010315 (release) 
(NetBSD nb3)]
2. Linux 2.4.20-3-686 (Debian GNU/Linux), Python 
version 2.3.3 (#2, Jan 13 2004, 00:47:05) [GCC 3.3.3 
20040110 (prerelease) (Debian)]

Both machine generate the identical error:
AssertionError: Expected '1#1970-01-06 00:00:00#1' in:
1#1970-01-05 23:00:00#1 [...]

A few simple tests in the python shell (both machines)
>>> import time
>>> time.daylight
1
>>> time.timezone
-7200
>>> time.tzname
('EET', 'EEST')
>>> time.mktime(time.localtime(0))
0.0
>>> time.mktime(time.gmtime(0)) - time.timezone
-3600.0
>>> time.gmtime(0)
(1970, 1, 1, 0, 0, 0, 3, 1, 0)
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - time.
timezone
-3600.0
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, -1)) - time.
timezone
-3600.0


However, the only difference between the Linux and BSD 
machine is:
1. NetBSD
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-7200.0
2. Linux
>>> time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 1)) - time.
timezone
-3600.0

I also attached the results of the moin test just in case.

--
Marti

Logged In: YES 
user_id=345221

Oops, forgot to check the upload box :)

Logged In: YES 
user_id=345221

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

Logged In: YES 
user_id=357491

OK, what I need is the result for ``time.localtime(0)`` (according to the 
calculations above should be three hours ahead of UTC, but in actuality, 
as long as the DST field is 0, should only be two hours ahead for EET) 
and ``time.mktime(time.gmtime(0))`` (should be -10800 according to 
the calculations above, but I want to double-check).  And the value of 
``time.altzone`` wouldn't hurt for trying to deal with the slight 
difference between the two OSs (should be -3600, or 1 hour ahead of 
UTC, for DST in EET, right?  In other words, EET is two hours ahead of 
UTC normally and only one hour ahead during daylight savings).

It looks like time.localtime(0) is off by an hour for some odd reason.  
And as for the discrepency between platforms, it should be only an hour 
difference since you should be subtracting time.altzone with the DST flag 
set to 1 and not time.timezone .  So it looks like Linux is behaving 
correctly and NetBSD is being really screwy if that is the only difference 
between the platforms.

But, to be honest, from a quick glance and the code, the wrappers are so 
thin that I don't think it is going to be on our side.  But with the info 
above I should be able to figure out where the discrepency is coming 
from and be able to make sure whose fault it is.

Logged In: YES 
user_id=345221

Summary: This doesn't look like Python's fault. case closed.

bcannon wrote:
> In other words, EET is two hours ahead of UTC normally and 
only
> one hour ahead during daylight savings).
That is not exactly correct.
EET (Eastern European Time, in winter) is UTC+2h, and
EEST (Eastern European Summer Time) is UTC+3h (This is 
DST)
Reference: http://www.timeanddate.
com/library/abbreviations/timezones/eu/eet.html

The way I understand it, daylight should be 0 not 1. (DST 
hasn't begun yet.
Reference: http://www.timeanddate.com/worldclock/city.html?
n=242

Otherwise you're right: it's not even Python's fault! I got 
exactly the same results on my Linux machine when I tested it 
in C. So I suppose this case is closed.
struct tm format: {sec, min, hour, mday, mon, year, wday, 
yday, isdst}

daylight = 1
timezone = -7200
tzname = {"EET", "EEST"}
mktime(localtime(0)) = 0
mktime(gmtime(0)) - timezone = -3600
gmtime(0) = {0, 0, 0, 1, 0, 70, 4, 0, 0}
mktime({0, 0, 0, 1, 0, 70, 4, 0, 0}) - timezone = -3600
mktime({0, 0, 0, 1, 0, 70, 4, 0,-1}) - timezone = -3600
mktime({0, 0, 0, 1, 0, 70, 4, 0, 1}) - timezone = -3600

I attached the code of mktime.c just in case anybody would 
want to review it.

Belated comment for posterity: this looks like a DST "inversion" problem - the system zone information may have been incorrect causing the system to believe that the Epoch occurred in a DST period.