[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