I was recently looking at a ZIP file, and after some time, I noticed that 7Zip was not displaying a modification date/time:

And neither was explorer:

I took a look with my zipdump.py tool, and got this:

63 minutes ???

That output comes from Python's zipfile module, or the pyzipper module, depending on what modules you installed.

I did some research: in standard ZIP format, the field with the modification time is a DOSTIME format, and the field with the modification date is a DOSDATE format. There is no timezone information, and it's the local time of the modification timestamp of the file that is taken by the ZIP utility.

DOSTIME and DOSDATE are very old formats (DOS ...) and they are 2 bytes long, split into 3 fields of bits.

DOSTIME: 5 bits for the seconds divided by 2, 6 bit for the minutes, and 5 bits for the hours.

So I updated my zipdump tool to parse DOSTIME and DOSDATE formats when I use option -f to locate binary ZIP records. This is the output:

The filetime field has value 0x7FF0. Which translates to 0111 1111 1111 0000 in binary

or:

seconds/2: 10000 -> 16 -> 32 seconds

minutes: 111111 -> 63 -> 63 minutes

hours: 01111 -> 15 -> 15 hours.

So it's because the time is stored in DOSTIME format, that is is possible to have "illegal" times: 15 hours, 63 minutes and 32 seconds (BTW, seconds are always even numbers, because what is stored is seconds/2).

Notice also, that a file stored inside a ZIP file, has 2 binary records: one for the file with its (compressed) content, and another one for the directory entry (without the file content).

Both records have many redundant fields, including time & date. In the example I got, only the dir entry (called PK0102 in zipdump's output) had an illegal DOSTIME, not the fil entry (PK0304).

Thus, the reason why I saw no modification timestamp, was not that it was missing, but that the dir entry had an "illegal" DOSTIME value.

In a previous diary entry, I talked about a crc32 checksum: this checksum is for the stored file content, not for the records. So I can not use this checksum to validate the DOSTIME field: I don't know if it has been tampered with, or if it's a bug in some ZIP library.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com