> >>> os.path.getmtime('x.txt')
> >>> int(win32file.GetFileAttributesExW('x.txt')[-2])
> >>> int(win32file.GetFileAttributesExW('x.txt')[-2]) -
> (Win XP)
> is this a bug, or is there a issue with timezones/summer time?
> aren't time.time() values absolute?
had this issue again.
py_GetFileAttributesEx creates <PyTime> objects from (linear) FILETIME).
PyTime stores linear time as well (Windows VariantTime "DATE"), but the conversion is done via SYSTEMTIME - with hour,minute,... :-)
py_GetFileAttributesEx > PyObject_FromFILEX_INFO > PyWinObject_FromFILETIME > FileTimeToSystemTime > PyTime
Upon int(<PyTime>) the conversion from PyTime back to linear time is again done via SYSTEMTIME.
These conversions via SYSTEMTIME are somehow buggy and principally bogus (during daylight-saving transition hours) overall.
=> the bug should perhaps be fixed by computing Pytime.m_time directly from FILETIME via y = a*x + b
perhaps even better: GetFileAttributesEx should simply return Pythonic time.time() style linear time stamps, not PyTime.
(but not backwards compatible; possibly by a flag parameter)
Python example for linear time conversion:
"returns time.time() style seconds from FILETIME"
tutc = ft.dwHighDateTime * 4294967296L + ft.dwLowDateTime
tt = tutc * 100e-9 - 11644473600
Log in to post a comment.