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

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

[D. Ben Knoble]

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(-)

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

[Junio C Hamano]

"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…)

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

[D. Ben Knoble]

[Resending for list]

On Sun, Jun 14, 2026 at 5:52 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> "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…)

👍

> 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

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

[Jeff King]

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

[D. Ben Knoble]

On Mon, Jun 15, 2026 at 1:14 PM Jeff King <peff@peff.net> 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