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

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

Bugs item #2831327, was opened at 2009-08-03 17: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: Open
Resolution: None
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: 2009-08-06 11: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-06 10: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-04 13: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-04 11: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