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.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html