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
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
