Re: unable to pull from remote if commit date is in the future

From: Jeff King <peff@peff.net>
Date: Jun 20, 2016, 20:00 UTC
Message-ID: <20160620200011.GC3631@sigill.intra.peff.net>
In-Reply-To: <20160620194648.GB3631@sigill.intra.peff.net>

On Mon, Jun 20, 2016 at 03:46:49PM -0400, Jeff King wrote:

Show 11 quoted lines

> So to answer my own questions:
> 
>   $ git cat-file commit 23c07cc | egrep '^author|committer'
>   author Sean D'Epagnier <seandepagnier@gmail.com> 5758122296 -40643156
>   committer Sean D'Epagnier <seandepagnier@gmail.com> 5758122296 -40643156
> 
> Yes, the timezone really is that ridiculous value. No, the author and
> committer aren't different. According to GNU date, the correct timestamp
> is actually in 2152. Offhand, I'd guess that the timestamp exceeding
> 2^32 is getting converted somewhere inside git to a bogus value, and
> that's how we end up with 2106.

Ah, nope. Everything is working as designed.

5758122296 _is_ in 2152, but that's before we apply the author's timezone offset. :)

Timezones are supposed to be [+-]HHMM. So the -40643156 timezone is parsed as -406431 hours, 56 minutes. Which is about 46 years. Hence git printing 2106.

You _should_ be able to get the right answer by asking git for --date=local, but it doesn't seem to work. Looks like it is because our tm_to_time_t hits this code:

  if (year < 0 || year > 129) /* algo only works for 1970-2099 */
	return -1;

and the caller does not actually check the error. The resulting timezone is the screwed-up -40643156, which is perhaps how it got into the commit in the first place.

-Peff