Bugs item #902172, was opened at 2004-02-22 17:09
Message generated for change (Comment added) made by pboddie
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Marti (sipsick)
Assigned to: Brett Cannon (bcannon)
Summary: Timezone miscalculation (time.mktime)
Initial Comment:
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
----------------------------------------------------------------------
Comment By: Paul Boddie (pboddie)
Date: 2007-03-11 02:28
Message:
Logged In: YES
user_id=226443
Originator: NO
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.
----------------------------------------------------------------------
Comment By: Marti (sipsick)
Date: 2004-02-24 23:52
Message:
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.
----------------------------------------------------------------------
Comment By: Brett Cannon (bcannon)
Date: 2004-02-24 09:36
Message:
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.
----------------------------------------------------------------------
Comment By: Marti (sipsick)
Date: 2004-02-22 17:11
Message:
Logged In: YES
user_id=345221
Oops, forgot to check the upload box :)
----------------------------------------------------------------------
Comment By: Marti (sipsick)
Date: 2004-02-22 17:11
Message:
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. :-( )
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902172&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
