On Mon, Jun 20, 2016 at 09:49:47PM +0200, Eric Deplagne wrote: > On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote: > > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote: > > > > > Hmm. On closer inspection that commit 23c07cc that github shows with > > > date 2152-06-19 is already in my local branch. I got confused because > > > locally it is shown with a different date: `git log -1 --format='%ci' > > > 23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid. > > > > > > My system is running Debian unstable 64bit. Is git using the time > > > rendering methods from the C library (glibc 2.22-12)? > > > > No, git's time code is (mostly) internal routines. Can you show us the > > output of: > > > > git cat-file commit 23c07cc | egrep '^author|committer' > > > > Note also that some interfaces (like "git log", and GitHub) will show > > the author date by default, which might be different than the committer > > date. The "-40643156" timezone definitely looks suspicious, though. I'm > > curious if it is bad handling in the time code, or if the commit has > > corrupt ident lines. > > > > -Peff > > 2106 is the year of unsigned 32-bit unix time bug, would there be any relation ? In an extremely roundabout way, yes. That -40643156 time zone really is "minus 46 years", but it was generated by _different_ code trying to compute the author timezone on the fly and using a stray "-1". So I suspect that no matter what time you ask for in the year 2152 (or later), the same process would end up with the 2106 time, as the timezone is custom-computed to end up back at the same error point. -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