[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 ldeller
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: 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