bpo-43848: explain optional argument mtime in gzip.py. #25410
Conversation
|
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA). CLA MissingOur records indicate the following people have not signed the CLA: For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. If you have recently signed the CLA, please wait at least one business day You can check yourself to see if the CLA has been received. Thanks again for the contribution, we look forward to reviewing it! |
jwuttke
changed the title
Misc/NEWS.d/next/Documentation/2021-04-14-19-24-39.bpo-43848.gjIRIY.rst
Outdated
Show resolved
Hide resolved
|
This PR is stale because it has been open for 30 days with no activity. |
|
Explaining the format is good. Could you also add it to the docs at https://docs.python.org/3.11/library/gzip.html#gzip.GzipFile.mtime, which is what most people will see? ( |
Explain data type of mtime. Reommend mtime = 0 for deterministic compression.
ReST, not MarkDown
…iption of attribute mtime
Good suggestion. Thanks. Is done now. I edited the descriptions of both the argument and the attribute mtime. In the latter, I removed a paragraph that was more confusing than helpful. |
| should only be provided in compression mode. If omitted or ``None``, the | ||
| current time is used. See the :attr:`mtime` attribute for more details. | ||
| The optional *mtime* argument is the timestamp requested by gzip. The time | ||
| is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. |
There was a problem hiding this comment.
| is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. | |
| is in Unix format, i.e., seconds since 00:00:00 UTC, January 1, 1970. |
Avoid abbreviations, and UTC is both more recognizable and more precise.
| current time is used. See the :attr:`mtime` attribute for more details. | ||
| The optional *mtime* argument is the timestamp requested by gzip. The time | ||
| is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. | ||
| If mtime is omitted or None, the current time is used. Use mtime = 0 |
There was a problem hiding this comment.
| If mtime is omitted or None, the current time is used. Use mtime = 0 | |
| If *mtime* is omitted or None, the current time is used. Use *mtime* = 0 |
| When decompressing, this attribute is set to last timestamp in the most | ||
| recently read header. It is an integer, holding the number of seconds | ||
| since the Unix epoch (00:00:00 GMT, Jan. 1, 1970). |
There was a problem hiding this comment.
| When decompressing, this attribute is set to last timestamp in the most | |
| recently read header. It is an integer, holding the number of seconds | |
| since the Unix epoch (00:00:00 GMT, Jan. 1, 1970). | |
| When decompressing, this attribute is set to the last timestamp in the most | |
| recently read header. It is an integer, holding the number of seconds | |
| since the Unix epoch (00:00:00 UTC, January 1, 1970). |
| to the last modification time field in the stream when compressing. | ||
| If omitted or None, the current time is used. | ||
| The optional mtime argument is the timestamp requested by gzip. The time | ||
| is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. |
There was a problem hiding this comment.
| is in Unix format, i.e., seconds since 00:00:00 GMT, Jan. 1, 1970. | |
| is in Unix format, i.e., seconds since 00:00:00 UTC, January 1, 1970. |
github-actions
bot
removed
the
stale
Explain data type of optional argument mtime.
Recommend mtime = 0 for deterministic compression.
This resolves https://bugs.python.org/issue43848.
See discussion [1,2] and gzip specification [3].
[1] https://mail.python.org/archives/list/python-dev@python.org/thread/OTUGLATLYB736SAPPRWSSXWAKM5JHWZN/
[2] https://discuss.python.org/t/gzip-py-allow-deterministic-compression-without-time-stamp/8221
[3] https://www.ietf.org/rfc/rfc1952.txt
https://bugs.python.org/issue43848