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.