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

[ctheune]

BPO	5457
Nosy	@rhettinger
Files	zipbug.py

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-03-09.22:58:33.384>
created_at = <Date 2009-03-09.09:38:28.683>
labels = ['type-bug', 'library']
title = 'ZipFile writes incorrect modification time (second is off-by-one)'
updated_at = <Date 2009-03-09.22:58:33.383>
user = 'https://bugs.python.org/ctheune'

bugs.python.org fields:

activity = <Date 2009-03-09.22:58:33.383>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2009-03-09.22:58:33.384>
closer = 'loewis'
components = ['Library (Lib)']
creation = <Date 2009-03-09.09:38:28.683>
creator = 'ctheune'
dependencies = []
files = ['13281']
hgrepos = []
issue_num = 5457
keywords = []
message_count = 2.0
messages = ['83364', '83366']
nosy_count = 2.0
nosy_names = ['rhettinger', 'ctheune']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5457'
versions = ['Python 2.6', 'Python 2.5', 'Python 2.4', 'Python 3.0']

[ctheune]

See the attached unit test. On seconds that are > 0 and < 60 the written
second is reduced by 1.

(The test doesn't explicitly prove that this happens during writing, but
we checked this manually. The read function is fine.)

[rhettinger]

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.