# [PATCH] doc: fix a small, old release notes typo 5 messages from 2026-06-14 to 2026-06-15. Participants: D. Ben Knoble, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/65810 ## D. Ben Knoble, 2026-06-14 17:28 Subject: [PATCH] doc: fix a small, old release notes typo Message-ID: <645638cd87d6d919af6d4310be8176d49fba326e.1781456960.git.ben.knoble+github@gmail.com> ``` Signed-off-by: D. Ben Knoble --- 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…) [1]: Documentation/RelNotes/2.14.0.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/2.14.0.adoc b/Documentation/RelNotes/2.14.0.adoc index 2711a2529d..182fbe6179 100644 --- a/Documentation/RelNotes/2.14.0.adoc +++ b/Documentation/RelNotes/2.14.0.adoc @@ -142,7 +142,7 @@ Performance, Internal Implementation, Development Support etc. historical use of ulong for timestamp would mean they cannot represent some timestamp that the platform allows. Invent a separate and dedicated timestamp_t (so that we can distinguish - timestamps and a vanilla ulongs, which along is already a good + timestamps and a vanilla ulongs, which alone is already a good move), and then declare uintmax_t is the type to be used as the timestamp_t. base-commit: 0c8ab3ebcc76981376809c8fe632d0fe18e93347 -- 2.54.0.1136.gdb2ca164c4.dirty ``` ## Junio C Hamano, 2026-06-14 21:52 Subject: Re: [PATCH] doc: fix a small, old release notes typo Message-ID: In-Reply-To: <645638cd87d6d919af6d4310be8176d49fba326e.1781456960.git.ben.knoble+github@gmail.com> ``` "D. Ben Knoble" writes: > Signed-off-by: D. Ben Knoble > --- > 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…) Unless it fixes a glaring factual error that would harm end-users if left unfixed, I would not very much be enthused to see fixes to these ancient documents, quite honestly. > separate and dedicated timestamp_t (so that we can distinguish > - timestamps and a vanilla ulongs, which along is already a good > + timestamps and a vanilla ulongs, which alone is already a good "timestamps and vanilla ulongs", as both are plural? ``` ## D. Ben Knoble, 2026-06-15 15:27 Subject: Re: [PATCH] doc: fix a small, old release notes typo Message-ID: In-Reply-To: ``` [Resending for list] On Sun, Jun 14, 2026 at 5:52 PM Junio C Hamano wrote: > > "D. Ben Knoble" writes: > > > Signed-off-by: D. Ben Knoble > > --- > > 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…) 👍 > Unless it fixes a glaring factual error that would harm end-users if > left unfixed, I would not very much be enthused to see fixes to > these ancient documents, quite honestly. > > > separate and dedicated timestamp_t (so that we can distinguish > > - timestamps and a vanilla ulongs, which along is already a good > > + timestamps and a vanilla ulongs, which alone is already a good > > "timestamps and vanilla ulongs", as both are plural? Indeed ``` ## Jeff King, 2026-06-15 17:14 Subject: Re: [PATCH] doc: fix a small, old release notes typo Message-ID: <20260615171416.GC91269@coredump.intra.peff.net> In-Reply-To: <645638cd87d6d919af6d4310be8176d49fba326e.1781456960.git.ben.knoble+github@gmail.com> ``` 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 ``` ## D. Ben Knoble, 2026-06-15 19:10 Subject: Re: [PATCH] doc: fix a small, old release notes typo Message-ID: In-Reply-To: <20260615171416.GC91269@coredump.intra.peff.net> ``` On Mon, Jun 15, 2026 at 1:14 PM Jeff King wrote: > > 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). Doh, that's the difference I missed. Thanks! > 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 Reminded me of https://williamzujkowski.github.io/posts/2026-04-02-building-us-code-tracker-law-as-git-history/ Thanks again, Ben ```