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