{"thread":{"id":"65810","subject":"[PATCH] doc: fix a small, old release notes typo","startedAt":"2026-06-14T17:28:35Z","lastAt":"2026-06-15T19:11:05Z","messageCount":5,"participants":["D. Ben Knoble","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"545491","messageId":"645638cd87d6d919af6d4310be8176d49fba326e.1781456960.git.ben.knoble+github@gmail.com","threadId":"65810","inReplyTo":null,"subject":"[PATCH] doc: fix a small, old release notes typo","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-06-14T17:28:31Z","receivedAt":"2026-06-14T17:28:35Z","isPatch":true,"body":"Signed-off-by: D. Ben Knoble \n---\nNo harm done if you choose not to keep this, I think. Stumbled upon it when\ntrying to understand Elijah's message [1] about timestamp_t overflowing in 2106\n(I though 32-bit time_t overflowed in 2038, but timestamp_t is something\ndifferent… except maybe when it's not? Anyway…)\n\n[1]: \n\n Documentation/RelNotes/2.14.0.adoc | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/Documentation/RelNotes/2.14.0.adoc b/Documentation/RelNotes/2.14.0.adoc\nindex 2711a2529d..182fbe6179 100644\n--- a/Documentation/RelNotes/2.14.0.adoc\n+++ b/Documentation/RelNotes/2.14.0.adoc\n@@ -142,7 +142,7 @@ Performance, Internal Implementation, Development Support etc.\n historical use of ulong for timestamp would mean they cannot\n represent some timestamp that the platform allows. Invent a\n separate and dedicated timestamp_t (so that we can distinguish\n- timestamps and a vanilla ulongs, which along is already a good\n+ timestamps and a vanilla ulongs, which alone is already a good\n move), and then declare uintmax_t is the type to be used as the\n timestamp_t.\n \n\nbase-commit: 0c8ab3ebcc76981376809c8fe632d0fe18e93347\n-- \n2.54.0.1136.gdb2ca164c4.dirty\n\n"},{"id":"545505","messageId":"xmqq1pe8eqmj.fsf@gitster.g","threadId":"65810","inReplyTo":"645638cd87d6d919af6d4310be8176d49fba326e.1781456960.git.ben.knoble+github@gmail.com","subject":"Re: [PATCH] doc: fix a small, old release notes typo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-06-14T21:52:52Z","receivedAt":"2026-06-14T21:52:55Z","isPatch":true,"body":"\"D. Ben Knoble\" writes:\n\n> Signed-off-by: D. Ben Knoble \n> ---\n> No harm done if you choose not to keep this, I think. Stumbled upon it when\n> trying to understand Elijah's message [1] about timestamp_t overflowing in 2106\n> (I though 32-bit time_t overflowed in 2038, but timestamp_t is something\n> different… except maybe when it's not? Anyway…)\n\nUnless it fixes a glaring factual error that would harm end-users if\nleft unfixed, I would not very much be enthused to see fixes to\nthese ancient documents, quite honestly.\n\n> separate and dedicated timestamp_t (so that we can distinguish\n> - timestamps and a vanilla ulongs, which along is already a good\n> + timestamps and a vanilla ulongs, which alone is already a good\n\n\"timestamps and vanilla ulongs\", as both are plural?\n\n"},{"id":"545590","messageId":"CALnO6CAzS818J4TRTNAa5s74RzvxJJ5=HXb24UnTxQzVPH9Khg@mail.gmail.com","threadId":"65810","inReplyTo":"xmqq1pe8eqmj.fsf@gitster.g","subject":"Re: [PATCH] doc: fix a small, old release notes typo","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-06-15T15:27:33Z","receivedAt":"2026-06-15T15:27:45Z","isPatch":true,"body":"[Resending for list]\n\nOn Sun, Jun 14, 2026 at 5:52 PM Junio C Hamano wrote:\n>\n> \"D. Ben Knoble\" writes:\n>\n> > Signed-off-by: D. Ben Knoble \n> > ---\n> > No harm done if you choose not to keep this, I think. Stumbled upon it when\n> > trying to understand Elijah's message [1] about timestamp_t overflowing in 2106\n> > (I though 32-bit time_t overflowed in 2038, but timestamp_t is something\n> > different… except maybe when it's not? Anyway…)\n\n👍\n\n> Unless it fixes a glaring factual error that would harm end-users if\n> left unfixed, I would not very much be enthused to see fixes to\n> these ancient documents, quite honestly.\n>\n> > separate and dedicated timestamp_t (so that we can distinguish\n> > - timestamps and a vanilla ulongs, which along is already a good\n> > + timestamps and a vanilla ulongs, which alone is already a good\n>\n> \"timestamps and vanilla ulongs\", as both are plural?\n\nIndeed\n"},{"id":"545603","messageId":"20260615171416.GC91269@coredump.intra.peff.net","threadId":"65810","inReplyTo":"645638cd87d6d919af6d4310be8176d49fba326e.1781456960.git.ben.knoble+github@gmail.com","subject":"Re: [PATCH] doc: fix a small, old release notes typo","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-06-15T17:14:16Z","receivedAt":"2026-06-15T17:14:18Z","isPatch":true,"body":"On Sun, Jun 14, 2026 at 01:28:31PM -0400, D. Ben Knoble wrote:\n\n> No harm done if you choose not to keep this, I think. Stumbled upon it when\n> trying to understand Elijah's message [1] about timestamp_t overflowing in 2106\n> (I though 32-bit time_t overflowed in 2038, but timestamp_t is something\n> different… except maybe when it's not? Anyway…)\n\nLeaving aside the patch for a moment, the answer to your timestamp\nquestion is: signed 32-bit takes us to 2038 (and back to 1902), but\nunsigned goes to 2106 (but only back to 1970).\n\nUsually time_t is signed, but our timestamp_t is not, mostly for\nhistorical reasons. And timestamp_t itself is our local invention\nbecause we have no control over the definition of time_t (but we still\nend up needing it to call system date functions).\n\nI have some patches to allow negative timestamps, but I ran into\nportability issues. IIRC, Windows gmtime() chokes on negative\ntimestamps.\n\nIt hasn't been a big deal in practice since new commits made today will\nalways have a positive epoch. But negative timestamps would allow\nimporting some historical projects (like Apollo mission code), as well\nas weird (ab)uses of Git to store historical documents (like legal code\ngoing back centuries).\n\n-Peff\n"},{"id":"545608","messageId":"CALnO6CDfs7uODE16HkvUfcqmv90okUjrCtGKOn0dae=Cd0j8Bw@mail.gmail.com","threadId":"65810","inReplyTo":"20260615171416.GC91269@coredump.intra.peff.net","subject":"Re: [PATCH] doc: fix a small, old release notes typo","fromName":"D. Ben Knoble","fromEmail":"ben.knoble+github@gmail.com","sentAt":"2026-06-15T19:10:53Z","receivedAt":"2026-06-15T19:11:05Z","isPatch":true,"body":"On Mon, Jun 15, 2026 at 1:14 PM Jeff King wrote:\n>\n> On Sun, Jun 14, 2026 at 01:28:31PM -0400, D. Ben Knoble wrote:\n>\n> > No harm done if you choose not to keep this, I think. Stumbled upon it when\n> > trying to understand Elijah's message [1] about timestamp_t overflowing in 2106\n> > (I though 32-bit time_t overflowed in 2038, but timestamp_t is something\n> > different… except maybe when it's not? Anyway…)\n>\n> Leaving aside the patch for a moment, the answer to your timestamp\n> question is: signed 32-bit takes us to 2038 (and back to 1902), but\n> unsigned goes to 2106 (but only back to 1970).\n>\n> Usually time_t is signed, but our timestamp_t is not, mostly for\n> historical reasons. And timestamp_t itself is our local invention\n> because we have no control over the definition of time_t (but we still\n> end up needing it to call system date functions).\n\nDoh, that's the difference I missed. Thanks!\n\n> I have some patches to allow negative timestamps, but I ran into\n> portability issues. IIRC, Windows gmtime() chokes on negative\n> timestamps.\n>\n> It hasn't been a big deal in practice since new commits made today will\n> always have a positive epoch. But negative timestamps would allow\n> importing some historical projects (like Apollo mission code), as well\n> as weird (ab)uses of Git to store historical documents (like legal code\n> going back centuries).\n>\n> -Peff\n\nReminded me of https://williamzujkowski.github.io/posts/2026-04-02-building-us-code-tracker-law-as-git-history/\n\nThanks again,\nBen\n"}]}