&gt; What does putting a timestamp into gzip add?<p>Roundtripping the file&#x27;s mtime through compression&#x2F;decompression is convenient. Same reason why the original filename can be stored (roundtrip it in case the filename is truncated at one point e.g. by having the gzip archive move through an msdos system). Here&#x27;s how the spec defines it:<p><pre><code>    MTIME (Modification TIME)
            This gives the most recent modification time of the original
            file being compressed.
</code></pre>
Sadly the spec then goes on to recommend leaking the compression date:<p><pre><code>            The time is in Unix format, i.e.,
            seconds since 00:00:00 GMT, Jan.  1, 1970.  (Note that this
            may cause problems for MS-DOS and other systems that use
            local rather than Universal time.)  If the compressed data
            did not come from a file, MTIME is set to the time at which
            compression started.  MTIME = 0 means no time stamp is
            available.
</code></pre>
<i>However</i> note that the spec recommends a unix timestamp, which is ~UTC, and doesn&#x27;t include the space for a timezone. Reading the POC[0] it apparently assumes any non-zero mtime is immediate (ignoring cached assets) and local.<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;jcarlosn&#x2F;gzip-http-time&#x2F;blob&#x2F;master&#x2F;time.php#L29" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jcarlosn&#x2F;gzip-http-time&#x2F;blob&#x2F;master&#x2F;time....</a>