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

From: Matthew E. Luallen <m@sph3r3.com>
Date: Oct 5, 2026, 13:48 UTC
Message-ID: <CA+h9NxRT-9QzLGihdL_Bp-yyt1AdXJ79YYgpK-OaegUz8e+HcA@mail.gmail.com>

Hello Git community,

I'm reporting three date-handling bugs reproduced on Apple Git 2.50.1 and upstream Git 2.56.0:

1. Exporting a 1972-dated commit with git archive --format=zip produces
   a legacy DOS date interpreted as 2100, while the extended Unix
   timestamp retains 1972.
2. Exporting a commit at epoch 4294967296 (2106-02-07 06:28:16 UTC)
   wraps ZIP's four-byte extended timestamp to zero (1970). Exporting
   the same commit as TAR preserves the original value.
3. git fast-import --date-format=raw accepts -32184000 +0000, but
   git fsck --strict then reports badDate and ISO rendering returns
   literal placeholders. This occurs in strict raw mode, not just
   the deliberately permissive import mode.

For the archive cases, export the dated commit with:

    git archive --format=zip <commit> > test.zip
    git archive --format=tar <commit> > test.tar

Compare the ZIP DOS and extended timestamp fields with the TAR mtime. The overflow affects consumer behavior: in macOS tests, UnZip update mode retained different existing 2025 content because the 2106 ZIP appeared older. An in-range 2038 ZIP replaced that content.

What range-handling policy should ZIP use, and should strict raw import reject timestamps that fsck considers invalid?

Thank you, Matthew E. Luallen (@meluallen) With research, reproduction, and drafting assistance from OpenAI Codex.