Re: [BUG] ZIP timestamp conversion and strict fast-import date validation

From: René Scharfe <l.s.r@web.de>
Date: Oct 7, 2026, 15:33 UTC
Message-ID: <6abe7f35-a1e4-4870-88d5-45ee40f5a061@web.de>
In-Reply-To: <CA+h9NxQEJaKrbTXUeryEhNMfOfuU0EykiJRi3PaJE9dRFo5tWw@mail.gmail.com>

On 10/5/26 10:32 PM, Matthew E. Luallen wrote:

> 
> - Reader example: Python 3.14.7's ZipInfo.date_time reports 2100 for
>   the 1972 ZIP despite its correct Unix timestamp.

Makes sense. Its source code, https://github.com/python/cpython/blob/3.14/Lib/zipfile/__init__.py, contains a decode function for two extra fields, Zip64 (0x0001) and Info-ZIP Unicode Path (0x7075), but no support for UNIX (0x000d). And why should it?

> - Separate consequence: the 2106-to-1970 wrap caused UnZip update mode
>   to retain different existing 2025 content. The 2038 control updated
>   correctly. No deployed security bypass has been demonstrated.

I'm not aware of a ZIP extension that allows storing arbitrary dates. I see three options:

- Don't color outside the lines, only emit ZIP files with valid DOS
  and UNIX timestamps and refuse to write earlier or later ones,

- wrap consistently, which can be confusing, but allows users to
  recover the original timestamp when they supply the higher bits
  (like we can say twenties now to mean 202x and 30 years ago we
  meant 192x), or

- map all earlier timestamps to the epoch and later ones to the maximum
  value, effectively stopping time at the borders -- all mtimes will be
  0xffffffff forever after that point is crossed, making them useless,
  except as a marker that a yet to be invented extension needs to be
  consulted to get the real mtime value.

> - Fix direction: would you prefer clamping or rejecting ZIP timestamps
>   beyond the Unix field's range? Our candidate rejects them. Would
>   rejecting negative dates in strict raw import be a useful first step?

Rejecting non-representable timestamps when creating ZIP files seems like the most honest option. Perhaps it's annoying enough to motivate people to find a proper solution? Which could be "use the tar format".

It would be nice if there was an example to follow. Info-ZIP zip(1) clamping at the low end and rolling over at the high end seems odd, though.

Rejecting negative timestamps on fast-import or at all seems bad for people who want to import ancient records. Git commit objects store timestamps as decimal numeric strings, so they can support arbitrarily high and low values. Importing mainframe file versions from the sixties or versions of legal documents from the last few hundred years don't seem too outlandish.

timestamp_t, Git's in-memory representation, is unsigned for historical reasons, but that is not necessarily fixed in stone.

René