patchdoc: fix a small, old release notes typo
5 messages between Jun 14, 2026 and Jun 15, 2026, from D. Ben Knoble, Junio C Hamano, Jeff King.
Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.
Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
---
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]: <pull.2148.git.1781420271100.gitgitgadget@gmail.com>
Documentation/RelNotes/2.14.0.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Show changes to Documentation/RelNotes/2.14.0.adoc +1 −1
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
Re: [PATCH] doc: fix a small, old release notes typo
"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
Show 6 quoted lines
> Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
> ---
> 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?
Re: [PATCH] doc: fix a small, old release notes typo
[Resending for list]
On Sun, Jun 14, 2026 at 5:52 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
>
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
>
> > Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
> > ---
> > 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…)
Show 9 quoted lines
> 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?
Re: [PATCH] doc: fix a small, old release notes typo
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
Re: [PATCH] doc: fix a small, old release notes typo
On Mon, Jun 15, 2026 at 1:14 PM Jeff King <peff@peff.net> wrote:
Show 16 quoted lines
>
> 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!
Show 11 quoted lines
> 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