[pywin32-bugs] [ pywin32-Bugs-2831327 ] GetProcessTimes converts wrongly to PyTime

[SourceForge.net <no...@so...>]

Bugs item #2831327, was opened at 2009-08-03 00:22
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&group_id=78018

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: win32
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Private: No
Submitted By: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetProcessTimes converts wrongly to PyTime

Initial Comment:
win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds.  It appears that Windows returns a UTC time, but this is interpreted as if it were a local time.

See attached example which demonstrates the bug.

A similar problem probably exists with the win32process.GetThreadTimes function.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2012-01-01 23:39

Message:
I'm reluctant to fix this, as (1) fixing it now could cause programs to
break as they may already be working around the problem by applying the UTC
offset manually, and (b) as the problem doesn't exist in the py3k version
which uses datetime objects.  I'm open to other ideas or thoughts though -
for people who care, it might be best to start a thread on the python-win32
list where the opinions of others can also be heard.  One useful concrete
idea might be to allow a runtime flag be used so py2k can also use datetime
objects but I'm not even sure that is worth the effort given py3k usage
seems to be growing significantly.

----------------------------------------------------------------------

Comment By: Pascal Chambon (pchambon)
Date: 2009-12-13 02:04

Message:
I've had a hard time with that bug too :p
The problem is that indeed the current pywin32 implementation uses
FileTimeToSystemTime to get an UTC datetime, but then when converting to
unix timestamp it uses mktime which expects localtime and automatically
guesses the timzone/daylightsaving, so we get wrong values.

Couldn't we just remove the #undef which prevents using python datetime api
before py3k ? Or replace FileTimeToSystemTime  by FileTimeToLocalTime and
only work with local pytimes, by adding
(SystemTimeToTzSpecificLocalTime(NULL, &st, &lt)) after
FileTimeToSystemTime(&t, &st); ?


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2009-08-05 18:05

Message:
Good catch - I should therefore nuke that function supporting a SYSTEMTIME
seeing we have managed without *really* needing one so far...

----------------------------------------------------------------------

Comment By: lplatypus (ldeller)
Date: 2009-08-05 17:40

Message:
That sounds good to me.  I see that the code for the py3k builds assumes
that SYSTEMTIME always contains UTC, which contradicts the MSDN
documentation for SYSTEMTIME [
http://msdn.microsoft.com/en-us/library/ms724950%28VS.85%29.aspx ].  Maybe
this is not so bad: the only example I can find where SYSTEMTIME contains a
local time is the return value of GetLocalTime(), and pywin's wrapper for
this function return a tuple thus sidestepping the problem.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2009-08-03 20:06

Message:
Note the py3k builds use a datetime objects; I think a better solution is
to allow these objects to also be used in py2k and let the PyTime object
die a graceful death...

----------------------------------------------------------------------

Comment By: lplatypus (ldeller)
Date: 2009-08-03 18:15

Message:
Following through the C++ code, I see that the type conversion sequence
is:
FILETIME -> SYSTEMTIME -> DATE -> struct tm -> time_t

Now with MSDN documentation handy I see that:
- FILETIME is always UTC
- SYSTEMTIME can be either UTC or the system's local time depending on the
function being called
- DATE documentation does not mention timezones at all
- struct tm can contain UTC or the system's local time
- time_t is always UTC

In the present example, we have a UTC time all the way through to struct
tm, but then it is converted to time_t using the mktime() function which
expects the struct tm to be in local time.  This occurs in PyTime::asLong()
in PyTime.cpp

How to fix this?  I think that the PyTime object needs to be extended to
know whether it contains UTC or local time. When constructed from a
FILETIME value it needs to be marked as containing UTC.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&group_id=78018