Matthew Luallen reported three issues reproduced on Apple Git 2.50.1 and upstream Git 2.56.0. First, a 1972-dated commit exported with git archive --format=zip gets a legacy DOS date that reads as 2100, while the extended Unix timestamp keeps 1972. Second, a commit at epoch 4294967296 (2106) wraps ZIP's four-byte extended timestamp to zero, while a TAR export preserves it. Third, git fast-import --date-format=raw accepts -32184000 +0000, but git fsck --strict then reports badDate.

René Scharfe explained that DOS timestamps start in 1980 and Unix timestamps in 1970, so no DOS value for 1972 exists, but the code could do better. He noted that zip(1) clamps such timestamps to the DOS epoch, 1980-01-01 00:00:00. He asked whether anything uses the DOS timestamp when a Unix timestamp is present. He also noted that tar can represent 1970 to 2242 with standard headers and beyond with extended headers, that a value above 4294967295 cannot fit the four-byte ZIP field, and that Git could clamp to that value, though zip(1) wraps around.

Luallen gave Python 3.14.7's ZipInfo.date_time as a reader that shows 2100 for the 1972 archive, while the tested UnZip and bsdtar restored 1972 correctly. He said the 2106 wrap is a separate problem: it made UnZip update mode keep existing 2025 content, whereas a 2038 control replaced it correctly. He added that no deployed security bypass has been demonstrated.

Luallen asked whether maintainers prefer clamping or rejecting ZIP timestamps beyond the Unix field's range; his candidate fix rejects them. He also asked whether rejecting negative dates in strict raw import would be a useful first step. No decision has been reached and no patch is shown in the excerpts.