Jeff King <p...@peff.net> writes: > On Wed, Mar 26, 2014 at 11:05:59AM +0000, Charles Bailey wrote: > >> On Mon, Feb 24, 2014 at 02:49:05AM -0500, Jeff King wrote: >> > +# date is within 2^63-1, but enough to choke glibc's gmtime >> > +test_expect_success 'absurdly far-in-future dates produce sentinel' ' >> > + commit=$(munge_author_date HEAD 999999999999999999) && >> > + echo "Thu Jan 1 00:00:00 1970 +0000" >expect && >> > + git log -1 --format=%ad $commit >actual && >> > + test_cmp expect actual >> > +' >> >> Git on AIX seems happy to convert this to Thu Oct 24 18:46:39 >> 162396404 -0700. I don't know if this is correct for the given input >> but the test fails. > > Ick. I am not sure that dates at that range are even meaningful (will > October really exist in the year 162396404? Did they account for all the > leap-seconds between then and now?). But at the same time, I cannot > fault their gmtime for just extrapolating the current rules out as far > as we ask them to. > > Unlike the FreeBSD thing that René brought up, this is not a problem in > the code, but just in the test. So I think our options are basically: > > 1. Scrap the test as unportable. > > 2. Hard-code a few expected values. I'd be unsurprised if some other > system comes up with a slightly different date in 162396404, so we > may end up needing several of these. > > I think I'd lean towards (2), just because it is testing an actual > feature of the code, and I'd like to continue doing so. And while we may > end up with a handful of values, there's probably not _that_ many > independent implementations of gmtime in the wild.
Or "3. Just make sure that 'git log' does not segfault"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
