On Mon, Jun 02, 2014 at 11:46:19PM -0400, Jeff King wrote: > On Fri, May 30, 2014 at 09:08:57AM +0100, Rodrigo Fernandes wrote: > > > Do you have any idea how does github understand that is a bug and > > fixes it automatically? > > (I'm saying this because on Github the date is correct). > > I looked into this. The dates you see on GitHub's web UI are actually > parsed by Rugged/libgit2. The libgit2 parser is slightly more forgiving > in this instance; if it sees a broken timezone, it will leave the > timestamp intact, and only omit the timezone. Whereas git says "no, it's > broken, and the timestamp cannot be trusted". > > I think both are equally valid strategies, and I do not even think it is > a problem that they diverge between the two implementations. I'd be OK > with a patch to make git handle errors in each independently, assuming > it is not too invasive.
I think what libgit2 does is more wrong than what git does. It displays the timestamp subtly wrong (off by 7 hours) instead of making it completely clear that the timestamp is bogus. -- Dennis Kaarsemaker <den...@kaarsemaker.net> http://twitter.com/seveas -- 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
