git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] t4212: handle systems with post-apocalyptic gmtime

From
Jeff King <peff@peff.net>
Date
Mar 27, 2014, 22:48 UTC
Message-ID
<20140327224837.GB32434@sigill.intra.peff.net>
In-Reply-To
<20140326224616.GA9454@hashpling.org>
On Wed, Mar 26, 2014 at 10:46:16PM +0000, Charles Bailey wrote:
Show 25 quoted lines
> On Wed, Mar 26, 2014 at 05:57:41PM -0400, Jeff King wrote:
> > Hmm, so the year you got is actually: 1623969404. That still seems off
> > to me by a factor 20. I don't know if this is really worth digging into
> > that much further, but I wonder what you would get for timestamps of:
> > 
> >   99999999999999999
> >   9999999999999999
> >   999999999999999
> >   etc.
> > 
> 
> AIX goes negative at about the same time Linux and Solaris segfault:
> 
> 9999999 Sun Apr 26 10:46:39 1970 -0700
> 99999999 Sat Mar 3 02:46:39 1973 -0700
> 999999999 Sat Sep 8 18:46:39 2001 -0700
> 9999999999 Sat Nov 20 10:46:39 2286 -0700
> 99999999999 Wed Nov 16 02:46:39 5138 -0700
> 999999999999 Thu Sep 26 18:46:39 33658 -0700
> 9999999999999 Sun May 20 10:46:39 318857 -0700
> 99999999999999 Sat Nov 7 02:46:39 3170843 -0700
> 999999999999999 Sat Jul 4 18:46:39 31690708 -0700
> 9999999999999999 Sat Jan 25 10:46:39 316889355 -0700
> 99999999999999999 Wed Sep 6 02:46:39 -1126091476 -0700
> 999999999999999999 Thu Oct 24 18:46:39 1623969404 -0700

Thanks. Given the value where it fails, it kind of looks like there is some signed 32-bit value at work (~300 million years is OK, but 10 times that, rather than yielding ~3 billion, gets us -1 billion). Perhaps tm.tm_year is 32-bit.

So what do we want to do? I think the options are:
  1. Try to guess when we have a bogus timestamp value with an arbitrary
     cutoff like "greater than 1 million years from now" (and enforce it
     via time_t seconds, and avoid gmtime entirely). That is made-up and
     arbitrary, but it also is sufficiently far that it won't ever
     matter, and sufficiently close that any gmtime should behave
     sensibly with it.
  2. Accept that we can't guess at every broken gmtime's output, and
     just loosen the test to make sure we don't segfault.
-Peff
Previous: Charles BaileyNext: Junio C Hamano
Message 29 of 48 in “handle bogus commit dates”
  1. 0/5 handle bogus commit datesJeff King, Feb 24, 2014
  2. 1/5 t4212: test bogus timestamps with git-logJeff King, Feb 24, 2014
  3. 2/5 fsck: report integer overflow in author timestampsJeff King, Feb 24, 2014
  4. 3/5 date: check date overflow against time_tJeff King, Feb 24, 2014
  5. 4/5 log: handle integer overflow in timestampsJeff King, Feb 24, 2014
  6. Junio C HamanoFeb 24, 2014
  7. Jeff KingFeb 24, 2014
  8. Junio C HamanoFeb 24, 2014
  9. Jeff KingFeb 24, 2014
  10. Junio C HamanoFeb 24, 2014
  11. 5/5 log: do not segfault on gmtime errorsJeff King, Feb 24, 2014
  12. René ScharfeMar 22, 2014
  13. Jeff KingMar 24, 2014
  14. René ScharfeMar 24, 2014
  15. Jeff KingMar 24, 2014
  16. Charles BaileyMar 26, 2014
  17. Jeff KingMar 26, 2014
  18. t4212: handle systems with post-apocalyptic gmtimeJeff King, Mar 26, 2014
  19. Junio C HamanoMar 26, 2014
  20. Jeff KingMar 26, 2014
  21. Jeff KingMar 26, 2014
  22. Jeff KingMar 26, 2014
  23. Charles BaileyMar 26, 2014
  24. Jeff KingMar 26, 2014
  25. Charles BaileyMar 26, 2014
  26. Charles BaileyMar 26, 2014
  27. Jeff KingMar 26, 2014
  28. Charles BaileyMar 26, 2014
  29. Jeff KingMar 27, 2014
  30. Junio C HamanoMar 28, 2014
  31. Jeff KingMar 28, 2014
  32. Junio C HamanoMar 28, 2014
  33. Jeff KingMar 28, 2014
  34. Junio C HamanoMar 28, 2014
  35. Jeff KingApr 1, 2014
  36. 1/2 date: recognize bogus FreeBSD gmtime outputJeff King, Apr 1, 2014
  37. René ScharfeApr 1, 2014
  38. Junio C HamanoApr 1, 2014
  39. René ScharfeApr 1, 2014
  40. Jeff KingApr 1, 2014
  41. 2/2 t4212: loosen far-in-future test for AIXJeff King, Apr 1, 2014
  42. work around unreliable gmtime errors on AIXJeff King, Apr 1, 2014
  43. Junio C HamanoApr 1, 2014
  44. Jeff KingApr 1, 2014
  45. Junio C HamanoMar 26, 2014
  46. Jeff KingMar 26, 2014
  47. Junio C HamanoMar 26, 2014
  48. Jeff KingMar 26, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.