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

From: René Scharfe <l.s.r@web.de>
Date: Oct 5, 2026, 19:49 UTC
Message-ID: <f8dc40a4-920d-4dc5-9f71-7686bfc6255b@web.de>
In-Reply-To: <CA+h9NxRT-9QzLGihdL_Bp-yyt1AdXJ79YYgpK-OaegUz8e+HcA@mail.gmail.com>

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

Show 8 quoted lines

> 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.

DOS timestamps can express years starting from 1980. Unix timestamps start at 1970. We can't provide a DOS timestamp for 1972, but can we do better? zip(1) clamps DOS timestamps to zero = the DOS epoch = 1980-01-01 00:00:00.

Is anything using the DOS timestamp even though a Unix timestamp is present?

> 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.

tar's timestamp can range from 1970 to 2242 with standard headers and beyond indefinitely with extended headers.

We cannot put a higher value than 4294967295 into the four-byte field provided by the Unix time extension for ZIP, but we could clamp to that value. zip(1) wraps around as well, though..

(I'm using "Zip 3.0 (July 5th 2008), by Info-ZIP, with modifications by Apple Inc.")

> 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.

Well, raw mode passes on the timestamp value with only little checks. strtoul(3) used in builtin/fast-import.c::validate_raw_date() happily accepts negative numbers. The latter function contains two NEEDSWORK comments about perhaps adding more checks, though.

René