#440 GetProcessTimes converts wrongly to PyTime

win32 (141)

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.


  • lplatypus

    lplatypus - 2009-08-03


  • lplatypus

    lplatypus - 2009-08-04

    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.

  • Mark Hammond

    Mark Hammond - 2009-08-04

    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...

  • lplatypus

    lplatypus - 2009-08-06

    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.

  • Mark Hammond

    Mark Hammond - 2009-08-06

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

  • Pascal Chambon

    Pascal Chambon - 2009-12-13

    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); ?

  • Mark Hammond

    Mark Hammond - 2012-01-02

    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.

  • Mark Hammond

    Mark Hammond - 2012-01-02
    • status: open --> closed-wont-fix

Log in to post a comment.