[issue5457] ZipFile writes incorrect modification time (second is off-by-one)

[Raymond Hettinger]

Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This appears to be an intrinsic limitation built into a zipfile's
standard file header format.  The header conforms to
http://www.pkware.com/documents/casestudies/APPNOTE.TXT where the date
and time fields are specified to be stored in the MS-DOS standard
date/time format detailed at
http://www.vsft.com/hal/dostime.htm.  In that format, there are only
five bits allocated for seconds.  Accordingly, seconds are stored
without their least significant bit (see the first few lines of
Zipfile.Fileheader where the seconds are encoded with dt[5] // 2).  Upon
decoding, the seconds are scaled back up (see the _RealGetContents()
method where the decoding is (t&0x1F) * 2).

Since zipfiles are supposed to be cross-platform and the file-format is
fixed, I don't see a way to remove this restriction.  Recommending to
close as wont-fix.

----------
message_count: 1.0 -> 2.0
nosy: +rhettinger
nosy_count: 1.0 -> 2.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5457>
_______________________________________