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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> So to answer my own questions:
> 
>   $ git cat-file commit 23c07cc | egrep '^author|committer'
>   author Sean D'Epagnier <seandepagnier@xxxxxxxxx> 5758122296 -40643156
>   committer Sean D'Epagnier <seandepagnier@xxxxxxxxx> 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
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]