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.
That's part of the explanation. That explains why the symptom doesn't
show up on FAT systems, but not what the symptom is really about.
When converting UCT to local time, there are two reasonable algorithms.
For most people, one of them makes sense, so the other sounds like a
bug. But people are very split as to which one is the "right" one.
If you're converting the current time to local, it seems logical that
you'd add the timezone offset, adjust for daylight-savings if it's
"summer," and be done. And if two people do it in two different time
zones they'd get different answers for "now." Likewise if one of them
is in a state or country that doesn't honor dst, they'd be off by an hour.
But what's the "right" answer for a file timestamp, or for any other
historical date/time? If the file (on a laptop, NTFS, say) was created
in California, and being examined in Maine a few months later, you'd
expect that the Maine time zone would be used. After all, the file
system doesn't store the fact that the laptop happened to be in
California when the file was created.
But what about the dst (daylight-savings) conversion? That's the
problem. One philosophy says it should be the dst state that was in
effect at the time the file was created, while the other applies the dst
state at the time of the conversion. If I recall correctly, getmtime()
uses the first approach, while GetFileAttributesExW() (and DIR) use the
second.
The net effect of this is that if last winter you created a file at 3pm,
and you have NOT changed time zones, then when you look at that file now
with GetFileAttributesExW() it'll tell you it was created at 4pm.
Notice that remote file access can complicate this, as can programs that
store the time stamp in local time. I ran into this problem many years
ago when saving digests of files to later check for corruption. I
suspect you'd have the same problem when restoring a file from CD, if
daylight savings time has changed. It's time stamp would be recreated
wrong. Similarly zip files or other archives. I've even run into
something similar on a FAT drive, when I ran across a file that was
created during the "impossible" time each spring between 2 and 3am on
dst-day.
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
