Generated zips store the current time, so they aren't reproducible

[nahuel]

When you generate a .zip file using mod_zip, the current time (the one of the nginx host) is always stored inside the .zip. Here the time is read:

mod_zip/ngx_http_zip_file.c

Line 296 in 255cf54

unix_time = time(NULL);

This is later stored in the File Header/Last Modification Time/Date fields, the File Header/Extra Field parameter and in the .zip Central Directory. So the generated .zip file is always different unless you download it in the exact same second.

This affects resumability, because you can get inconsistent datetimes if you download the .zip file using multiple (Range) requests and some request starts from the middle offset of a datetime field bytes. Is also very troublesome when you need the .zip generated to be always the same (because you are check-summing the entire .zip file in a client application).

Possible fixes:

A- Modify mod_zip to store NULL/1970 dates on zips, making it the default behaviour or one behind an option.
B- Get the file dates from upstream files "Last-Modified" headers
C- Add a new date field to the space-separated file list.

[nanaya]

Would a PR just removing the date (setting it to null/1970) be accepted as interim fix? I think it's still better than having inconsistent response.