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>
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