Running on Windows XP against a networked file server with Windows 2003 I have a file which due to some obscure reason it has a negative modification time as returned by Python os functions. When I look at the file in the explorer the modification time column is blank, and when I view the properties of the file there the modification time is set to the 25th of April of 1906 at 2:03:44.

If I try to zip this file the zip creation fails with a Value error when the file's st_mtime value is passed to time.localtime().

I'm attaching a debug session log along with a possible patch to avoid such problems, though maybe the function that returns st_mtime should never return negative values because other library functions expect zero or positive values too.

In the log you will see that it is a custom rastertech\zipfile.py file that is failing. This is just the SVN development version of zipfile along with some modifications since changes like 1739648 seem to be very low priority. The patch is generated against a clean SVN version.

File Added: ignore_negative_modification_time.txt

Any progress report on this issue, please?

At the moment I don't have a Windows machine available, but on my Mac,
time.localtime doesn't seem to mind interpreting negative input values.
 So I doubt that forcing timestamps to be non-negative is the way to fix
this. 

I poked around a bit in the current 2.6 source, and it seems to me that
in this case the Windows XP localtime function doesn't like a timestamp
value that was generated by the same platform's stat function.  It seems
like raising a ValueError is the correct thing for the time module to
do, since it relies on the platform to do the conversions; what should
zipfile.writestr do?  I don't like the idea of silently using some dummy
timestamp if the conversion of os.stat results fails, and I can't think
of an alternative at the moment.