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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4