Re: [Python-Dev] os.path.getmtime on Windows
Martin v. Löwis wrote: 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). No, I did not exit Python. The problem only appeared when I changed time zone. Changing the date had no effect. -- Christian Tismer :^) mailto:[EMAIL PROTECTED] tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
Phillip J. Eby wrote: Windows doesn't store UTC timestamps, at least not on older FAT filesystems and maybe not even on NTFS. Changing Python won't help. :) Windows definitely stores UTC timestamps on NTFS, in units of 100ns since Jan 1, 1601. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
Christian Tismer wrote: Is there a way to circumvent this problem, or am I missing something? If this is not the expected behavior, then it might make sense to find a patch. I have meant to work on a patch for several years now. I would like to drop usage of msvcrt's stat(3), and instead implement os.stat in terms of Windows API directly. That would also have the advantage that subsecond time-stamps can be exposed. There are several issues involved in implementing such a patch, though. One is that you need to do it twice: once for Win9x, and once for NT+, because you have to use Unicode file names on one system, and ANSI file names on the other. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
Hi Martin, Is there a way to circumvent this problem, or am I missing something? If this is not the expected behavior, then it might make sense to find a patch. I have meant to work on a patch for several years now. I would like to drop usage of msvcrt's stat(3), and instead implement os.stat in terms of Windows API directly. That would also have the advantage that subsecond time-stamps can be exposed. I see! Still trying to understand the story. I'm working through the article Tim pointed us at. http://www.codeproject.com/datetime/dstbugs.asp Does it mean that msvcrt does extra magic to modify the existing correct UTC entries? And would usage of the Windows API heal this immediately, or are extra steps involved? As I understand the article, things are different when a file is stored in a FAT or NTFS drive. Do you think the provided solution is worthwhile to be adapted for Python? http://www.codeproject.com/datetime/DstBugs/DstBugs.zip There are several issues involved in implementing such a patch, though. One is that you need to do it twice: once for Win9x, and once for NT+, because you have to use Unicode file names on one system, and ANSI file names on the other. Correcting it just for NT/XP would make the majority of people happy, IMHO. cheers - chris -- Christian Tismer :^) mailto:[EMAIL PROTECTED] tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
Christian Tismer wrote: Does it mean that msvcrt does extra magic to modify the existing correct UTC entries? Mostly, yes. For FAT, the system does also some conversion. Those conversions I don't fully understand, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/file_times.asp suggests that there are cached UTC times on FAT somewhere. And would usage of the Windows API heal this immediately, or are extra steps involved? If we use GetFileTime, apparently yes. FindFirstFile apparently also suffers from daylight conversion bugs when reading time stamps from FAT. As I understand the article, things are different when a file is stored in a FAT or NTFS drive. Correct. Do you think the provided solution is worthwhile to be adapted for Python? http://www.codeproject.com/datetime/DstBugs/DstBugs.zip No. If anything is done about this, it should be to drop msvcrt. There are several issues involved in implementing such a patch, though. One is that you need to do it twice: once for Win9x, and once for NT+, because you have to use Unicode file names on one system, and ANSI file names on the other. Correcting it just for NT/XP would make the majority of people happy, IMHO. Right - the question would be whether completely breaking W9x support in the process would be acceptable. We use the very same binaries for W9x and NT. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
On Sun, 15 Jan 2006 20:23:39 +0100, Martin v. Löwis wrote: There are several issues involved in implementing such a patch, though. One is that you need to do it twice: once for Win9x, and once for NT+, because you have to use Unicode file names on one system, and ANSI file names on the other. Right - the question would be whether completely breaking W9x support in the process would be acceptable. We use the very same binaries for W9x and NT. How about accessing/calling the wide char versions just if the OS is NT, i.e. compiling both versions into the dll and just using one? Looking at the file object, the open function uses _wfopen which needs Windows NT according to the MSDN lib. So, how is 9x compat ensured here? Kind regards, Alexander ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
Alexander Schremmer wrote: There are several issues involved in implementing such a patch, though. One is that you need to do it twice: once for Win9x, and once for NT+, because you have to use Unicode file names on one system, and ANSI file names on the other. Right - the question would be whether completely breaking W9x support in the process would be acceptable. We use the very same binaries for W9x and NT. How about accessing/calling the wide char versions just if the OS is NT, i.e. compiling both versions into the dll and just using one? Right. That's what I meant when I said: you need to do it twice. Looking at the file object, the open function uses _wfopen which needs Windows NT according to the MSDN lib. So, how is 9x compat ensured here? There is a GetVersion check in there; not sure how effective it is, though. However, if you pass byte strings, as the file name, _wfopen is not used. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
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(). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] os.path.getmtime on Windows
Hi Python developers, today I got a complaint from the python.de IRC channel about os.path.getmtime and time zone. How to produce the weird behavior: 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. I was not ableto produce an identity, neither by time.gmtime nor by time.localtime, so I'm a bit confused. I checked the sources, and this is probably not a Python problem. It uses the suggested win32 function properly. But the win32 documentation seems to have no hints about this. I assumend the value would be in UTC, but it is obviously not. Is there a way to circumvent this problem, or am I missing something? If this is not the expected behavior, then it might make sense to find a patch. thanks -- chris -- Christian Tismer :^) mailto:[EMAIL PROTECTED] tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/ 14109 Berlin : PGP key - http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
At 02:37 AM 1/15/2006 +0100, Christian Tismer wrote: I assumend the value would be in UTC, but it is obviously not. Is there a way to circumvent this problem, or am I missing something? If this is not the expected behavior, then it might make sense to find a patch. Windows doesn't store UTC timestamps, at least not on older FAT filesystems and maybe not even on NTFS. Changing Python won't help. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.getmtime on Windows
[Christian Tismer] Hi Python developers, today I got a complaint from the python.de IRC channel about os.path.getmtime and time zone. How to produce the weird behavior: 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. I was not ableto produce an identity, neither by time.gmtime nor by time.localtime, so I'm a bit confused. I checked the sources, and this is probably not a Python problem. It uses the suggested win32 function properly. But the win32 documentation seems to have no hints about this. I assumend the value would be in UTC, but it is obviously not. See: http://www.codeproject.com/datetime/dstbugs.asp and just be grateful you didn't bump into the additional mysteries MS added around daylight time switches. Is there a way to circumvent this problem, or am I missing something? If this is not the expected behavior, then it might make sense to find a patch. While I love the article linked to above, I've never had the will to force myself to read it all the way to the end ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
