Re: [PATCH] doc: fix a small, old release notes typo

[Jeff King <peff@peff.net>]

On Sun, Jun 14, 2026 at 01:28:31PM -0400, D. Ben Knoble wrote:

> No harm done if you choose not to keep this, I think. Stumbled upon it when
> trying to understand Elijah's message [1] about timestamp_t overflowing in 2106
> (I though 32-bit time_t overflowed in 2038, but timestamp_t is something
> different… except maybe when it's not? Anyway…)

Leaving aside the patch for a moment, the answer to your timestamp
question is: signed 32-bit takes us to 2038 (and back to 1902), but
unsigned goes to 2106 (but only back to 1970).

Usually time_t is signed, but our timestamp_t is not, mostly for
historical reasons. And timestamp_t itself is our local invention
because we have no control over the definition of time_t (but we still
end up needing it to call system date functions).

I have some patches to allow negative timestamps, but I ran into
portability issues. IIRC, Windows gmtime() chokes on negative
timestamps.

It hasn't been a big deal in practice since new commits made today will
always have a positive epoch. But negative timestamps would allow
importing some historical projects (like Apollo mission code), as well
as weird (ab)uses of Git to store historical documents (like legal code
going back centuries).

-Peff