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

["René Scharfe" <l.s.r@web.de>]

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é