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

[Robert]

Dave Angel wrote:
> 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.


Well I think, the integer time does/should generally aim at a 
absolute value as good as possible - time.time() and 
os.path.getmtime() seem to do. Nothing with local/dst. No problem, 
no loss of information (e.g. on NTFS). Even the term "UTC" doesn't 
make sense so far ( except for defining *verbally* the absolute 
start point 1.1.1970 XX:XX UTC )

http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx
"A file time is a 64-bit value that represents the number of 
100-nanosecond intervals that have elapsed since 12:00 A.M. 
January 1, 1601 Coordinated Universal Time (UTC). The system 
records file times when applications create, access, and write to 
files."

-> just a fix offset to Python time.time()

Guess this is wrong in win32file; or win32file looses info by 
early conversion to digits.

"local/timezone/dst.." just makes sense for display values: "wall 
clock digits".

When info is missing in time stamps / digits stored, like with FAT 
time stamps, then only the question arises, which assumptions to 
make on int-conversion - UTC/local time zone, or even DST. In that 
case its necessary to know (by an additional flag/attribute the 
assumption)


R