[Python-Dev] os.path.getmtime on Windows (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon Jan 16 01:06:16 CET 2006

Christian Tismer wrote:

1. create a file 2. get it's os.path.getmtime() 3. change your time zone 4. get os.path.getmtime again

compare - the time stamps are different. Change the time zone back, and they are identical, again.

Just to add an important detail here: I assume you did not exit Python between step 2 and step 4, right? (please confirm whether this is the case).

If so, it has nothing to do with daylight saving time.

If I start a new Python interpreter and fetch the mtime again, it will report the value I got at step 2.

This is on NTFS, so the time stamps the system reports (in FindFirstFile) are true UTC.

What happens is apparently this: msvcrt converts the UTC time to local time, using FileTimeToLocalFileTime; this gets the new time zone offset from the system. It then converts it back through __loctotime_t. This invokes __tzset, however, __tzset caches the _timezone offset, so it is unaffected by the time zone change.

So this specific problem goes away as soon as we start dropping msvcrt.

Regards, Martin

P.S. The other problem (FindFirstFile gives bad UTC time stamps on FAT, for files created in a different DST period) has no real solution, AFAICT. There is no portable way to determine whether the underlying file system stores time stamps in local time or in UTC, and even if you know that file stamps were in local time, you still couldn't reliably convert that to UTC (because of the repeated hour, and because of potential time zone changes).

So I would rather return to the user what the system gives me, knowing that a) the problem exists on FAT only, and people should use NTFS if they care about time stamps b) it is better to document the limitation instead of trying to work around it: msvcrt shows that attempts to work around it make the problem worse, not better. So I would like to use FindFirstFile for stat(), and GetFileType+GetFileInformationByHandle for fstat().

More information about the Python-Dev mailing list