Changes by Jacques Frechet :
Added file: http://bugs.python.org/file12529/gzip-mtime-revised-2.x.patch
___
Python tracker
<http://bugs.python.org/issue4272>
___
___
Pytho
Jacques Frechet added the comment:
I am uploading a new patch, identical to the previous patch except that
it does not contain the ill-advised third test case
(test_literal_output). The patch still applies cleanly and the tests
still pass.
Added file: http://bugs.python.org/file12528/gzip
Jacques Frechet <[EMAIL PROTECTED]> added the comment:
I'm no expert either. The output certainly seems to be deterministic
for a given version of zlib, and I'm not aware of any prior versions of
zlib that produce different compressed output. However, my
understanding is th
Jacques Frechet <[EMAIL PROTECTED]> added the comment:
This discussion of the problem and possible workarounds might also be of
interest:
http://stackoverflow.com/questions/264224/setting-the-gzip-timestamp-from-python
___
Python tracker <[EMAIL
Changes by Jacques Frechet <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11955/gzip-mtime-2.x.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
New submission from Jacques Frechet <[EMAIL PROTECTED]>:
The gzip header defined in RFC 1952 includes a mandatory "MTIME" field,
originally intended to contain the modification time of the original
uncompressed file. It is often ignored when decompressing, though
gunzip (for exa
