No. The FILETIME values in the WIN32_FIND_DATA structure are defined as the number of 100-nanosecond intervals since January 1, 1601 00:00 UTC on *all* Windows versions. Likewise, the behaviour of FileTimeToLocalFileTime, and the bug, is identical on NT and W9x.
Doesn't that contradict the comment in the CRT source? (Not that I necessarily believe that the comment must be correct.)
However this would be quite a hassle just because of an occasional 1 hour off on FAT volumes.
The occasional one hour difference can produce quite nasty bugs, not least because it's so occasional. But if it isn't cheap to check the filesystem type, we probably can't afford to do it anyway. And in my view it's more important that it works correctly on ntfs.
Summing up, I renew my pledge to replace the current Pike implementation with my proposed calculation.
Your theory makes sense. I'd just like to know what this Win32S and Win32C that the comment talks about is.
Btw, speaking of DST bugs, it seems GetFileTime, which is used by Stdio.File.stat, has an even more nasty one:
FAT records times on disk in local time. GetFileTime retrieves cached UTC times from FAT. When it becomes daylight saving time, the time retrieved by GetFileTime will be off an hour, because the cache has not been updated. When you restart the machine, the cached time retrieved by GetFileTime will be correct.
Firstly, I don't see why it would get incorrect; it's afterall cached in UTC where there's no such thing as DST. Secondly, provided it actually is incorrect, I wonder why they don't fix it instead of just documenting it. Are they still stuck in the "well, everyone reboots at least once a day anyway" paradigm?