[python-win32] File Time: win32file vs Python ?

Robert kxroberto at googlemail.com
Fri Jul 3 12:58:46 CEST 2009


Tim Roberts wrote:
> Robert wrote:
>>>>> os.path.getmtime('x.txt')
>> 1193160881
>>>>> int(win32file.GetFileAttributesExW('x.txt')[-2])
>> 1193153681
>>>>> int(win32file.GetFileAttributesExW('x.txt')[-2]) -
>> os.path.getmtime('x.txt')
>> -7200
>>
>> (Win XP)
>> is this a bug, or is there a issue with timezones/summer time? aren't
>> time.time() values absolute?
> 
> The meaning of time.time isn't really relevant to this. 
> GetFileAttributesExW returns values directly from the file system, and
> NTFS happens to store its timestamps in UTC.  os.path.getmtime adjusts
> to local time.
> 
> FAT file systems record timestamps in local time, which causes the
> reported times to change during summer time.
> 


hmm.. here os.path.getmtime() delivers exactly time.time() without 
any shift (NTFS)

 >>> open('x.txt','w').close(); time.time(); 
os.path.getmtime('x.txt'); 
int(win32file.GetFileAttributesExW('x.txt')[-2])
1246618638.25
1246618638.25
1246611438

and win32file/int(PyTime)has the -7200 time.altzone on it. Guess 
it doesn't make sense. Seems PyTime internally forces to "wall 
clock digits" only and __int__ doesn't even respect altzone.

Guess int-time values should never have local/summer on it? - 
(unless info is missing like on FAT.)


R



More information about the python-win32 mailing list