This test uses a dynamically generated zipfile to avoid having to store
very large objects in the git tree. The zipfile itself was produced
using the default linux zip utility.
The msdos datetime 0x00000000 is invalid. The Windows API would
(rightfully) return an ERROR_INVALID_PARAMETER for this when converting
it. If it is indeed an invalid error, we now return the zip datetime
'epoch' of 1980-01-01 00:00:00.
Resolves issue #61
I constructed this file using a hack from the Zip manpage: if the input to a
Zip compression command is streamed on standard input, the output is given in
ZIP64 format since the tool doesn't know how big the input will be. I modified
the resulting file by adding some leading junk text and editing the non-ZIP64
end-of-central-directory structure to have 0xFFFF for its "number of files"
parameters, to help the test demonstrate that the ZIP64 data are being
properly read. (0xFFFF is the value used in the non-ZIP64 structure if the
archive actually has more than 65535 files.)
