Roundtripping the file's mtime through compression/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's how the spec defines it:
MTIME (Modification TIME)
This gives the most recent modification time of the original
file being compressed.
Sadly the spec then goes on to recommend leaking the compression date:
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.
However note that the spec recommends a unix timestamp, which is ~UTC, and doesn'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.
Roundtripping the file's mtime through compression/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's how the spec defines it:
Sadly the spec then goes on to recommend leaking the compression date: However note that the spec recommends a unix timestamp, which is ~UTC, and doesn'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.[0] https://github.com/jcarlosn/gzip-http-time/blob/master/time....