Hmm, interesting. This is exactly what happened recently when debugging pyc timestamp issues under Windows:
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%202.7/builds/1204/steps/test/logs/stdio

Some decoding of the above crash:
- the test would set the .py file's timestamps to 2**33
- this is truncated (module 2**32) and therefore should become 0 in the .pyc file's embedded timestamp
- in reality, the .pyc file's embedded timestamps is equal to 4294963696. Which is 2**32 - 3600.

As a sidenote, we don't have any tests that the pyc file is re-used when it is fresh enough. Perhaps by running an interpreter in a subprocess with "-v" we could examine the verbose messages printed out in import.c.

> It seems as though the correct fix would be to use something like GetFileInformationByHandle in place of the fstat calls in import.c.

We must probably also replace the stat() call (through _Py_stat) with GetFileAttributesEx, or make _Py_stat re-use GetFileAttributesEx.