{"thread":{"id":"36781","subject":"[BUG REPORT] Git log pretty date","startedAt":"2014-05-29T10:29:11Z","lastAt":"2014-06-03T06:45:26Z","messageCount":13,"participants":["Rodrigo Fernandes","Duy Nguyen","Dennis Kaarsemaker","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"242927","messageId":"CACJZPBtv-Cpb8_WZMz9Hsk9MrC86YGfbvREt6G=QKvMBjrqsEg@mail.gmail.com","threadId":"36781","inReplyTo":null,"subject":"[BUG REPORT] Git log pretty date","fromName":"Rodrigo Fernandes","fromEmail":"rtfrodrigo@gmail.com","sentAt":"2014-05-29T10:29:11Z","receivedAt":"2014-05-29T10:29:11Z","isPatch":false,"sender":{"key":"rtfrodrigo@gmail.com","avatar":"https://gravatar.com/avatar/b94cfe8bec4897d79b90f493dea4edf132c4d09b73a19dc2932fcd902f6d38b4?d=mp&s=160"},"body":"Hi,\n\nI'm having some problems with the `git log` command.\n\nSetup:\nHappens in multiple versions, tested on 1.8.* and 2.*\n\nThe problem happens when I try to get a pretty log for a commit with a\nwrong date.\n\nExecuting the command:\n`git log --encoding=UTF-8 --date=raw --pretty=format:'%H,%P,%ad,%cd,%an,%s'`\n\nI get an empty response on the date field, but since pretty has `%ad`\nit should follow the --date and return the date even if wrong.\n\nThe problem happens in this repo:\n`https://github.com/SamWM/jQuery-Plugins` on commit\n`e9dddaf24c9de45d9b4efdf38eff7c30eb200f48`.\n\nI posted it on SO too:\n`http://stackoverflow.com/questions/23793188/find-date-for-not-dated-commit`\n\nI think it is a bug probably on pretty since other raw formats show\nthe date as it should.\n\nI tried to check the source code but have no idea where to start,\nmaybe if you point me on some direction I can take a look for my self.\n\nCan you help?\n\nKind regards,\nRodrigo Fernandes\n"},{"id":"242932","messageId":"CACsJy8BREpVFKq3mW=Lwn+uNm1r40Xe8f4EyXLFN2yybZRT0oA@mail.gmail.com","threadId":"36781","inReplyTo":"CACJZPBtv-Cpb8_WZMz9Hsk9MrC86YGfbvREt6G=QKvMBjrqsEg@mail.gmail.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-05-29T10:50:56Z","receivedAt":"2014-05-29T10:50:56Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 29, 2014 at 5:29 PM, Rodrigo Fernandes wrote:\n> I get an empty response on the date field, but since pretty has `%ad`\n> it should follow the --date and return the date even if wrong.\n>\n> ...\n>\n> I tried to check the source code but have no idea where to start,\n> maybe if you point me on some direction I can take a look for my self.\n\npretty.c, format_commit_one() -> format_person_part() ->\nshow_ident_date() -> show_date(). The last one is in date.c\n-- \nDuy\n"},{"id":"242933","messageId":"1401361654.26905.2.camel@spirit","threadId":"36781","inReplyTo":"CACJZPBtv-Cpb8_WZMz9Hsk9MrC86YGfbvREt6G=QKvMBjrqsEg@mail.gmail.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2014-05-29T11:07:34Z","receivedAt":"2014-05-29T11:07:34Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On do, 2014-05-29 at 11:29 +0100, Rodrigo Fernandes wrote:\n> \n> The problem happens when I try to get a pretty log for a commit with a\n> wrong date.\n\nThe commit is:\n\n===\n$ git cat-file commit e9dddaf24c9de45d9b4efdf38eff7c30eb200f48\ntree d63aeb159635cb231e191505a95a129a3b4a7b38\nparent 9276202f1c0dcc360433df222c90f7874558f072\nauthor SamWM 1288370243 --700\ncommitter SamWM 1288370243 --700\n\nUpdate version number, make text formatting and indentation consistent\nwith the rest of the code\n====\n\nThose dates are indeed wrong, I'm not surprised git refuses to parse\nthem.\n\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"242938","messageId":"CACJZPBvn4nX4aVGiiC1VAhHi7vPZJDBR8T5p13qaE6B+2Q9bUw@mail.gmail.com","threadId":"36781","inReplyTo":"1401361654.26905.2.camel@spirit","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Rodrigo Fernandes","fromEmail":"rtfrodrigo@gmail.com","sentAt":"2014-05-29T12:24:36Z","receivedAt":"2014-05-29T12:24:36Z","isPatch":false,"sender":{"key":"rtfrodrigo@gmail.com","avatar":"https://gravatar.com/avatar/b94cfe8bec4897d79b90f493dea4edf132c4d09b73a19dc2932fcd902f6d38b4?d=mp&s=160"},"body":"Dennis I think that could be an improvement.\n\nDuy, can you point me where is the date print from normal `git log` or\n`git show` so I can compare?\n\n\nOn Thu, May 29, 2014 at 12:07 PM, Dennis Kaarsemaker\n wrote:\n> On do, 2014-05-29 at 11:29 +0100, Rodrigo Fernandes wrote:\n>>\n>> The problem happens when I try to get a pretty log for a commit with a\n>> wrong date.\n>\n> The commit is:\n>\n> ===\n> $ git cat-file commit e9dddaf24c9de45d9b4efdf38eff7c30eb200f48\n> tree d63aeb159635cb231e191505a95a129a3b4a7b38\n> parent 9276202f1c0dcc360433df222c90f7874558f072\n> author SamWM 1288370243 --700\n> committer SamWM 1288370243 --700\n>\n> Update version number, make text formatting and indentation consistent\n> with the rest of the code\n> ====\n>\n> Those dates are indeed wrong, I'm not surprised git refuses to parse\n> them.\n>\n> --\n> Dennis Kaarsemaker\n> www.kaarsemaker.net\n>\n"},{"id":"242943","messageId":"CACsJy8CzMcaQ0q4bsUmR34fE+VunTFiW_oVmC-mKFORq89bsKQ@mail.gmail.com","threadId":"36781","inReplyTo":"CACJZPBvn4nX4aVGiiC1VAhHi7vPZJDBR8T5p13qaE6B+2Q9bUw@mail.gmail.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-05-29T12:52:50Z","receivedAt":"2014-05-29T12:52:50Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, May 29, 2014 at 7:24 PM, Rodrigo Fernandes wrote:\n> Duy, can you point me where is the date print from normal `git log` or\n> `git show` so I can compare?\n\nIt's the same function, show_date() in date.c.\n-- \nDuy\n"},{"id":"242965","messageId":"20140529161628.GB3763@sigill.intra.peff.net","threadId":"36781","inReplyTo":"CACsJy8BREpVFKq3mW=Lwn+uNm1r40Xe8f4EyXLFN2yybZRT0oA@mail.gmail.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-29T16:16:28Z","receivedAt":"2014-05-29T16:16:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 29, 2014 at 05:50:56PM +0700, Duy Nguyen wrote:\n\n> On Thu, May 29, 2014 at 5:29 PM, Rodrigo Fernandes wrote:\n> > I get an empty response on the date field, but since pretty has `%ad`\n> > it should follow the --date and return the date even if wrong.\n> >\n> > ...\n> >\n> > I tried to check the source code but have no idea where to start,\n> > maybe if you point me on some direction I can take a look for my self.\n> \n> pretty.c, format_commit_one() -> format_person_part() ->\n> show_ident_date() -> show_date(). The last one is in date.c\n\nshow_ident_date() recently learned to always print \"Jan 1 1970\" as a\nsentinel for dates that cannot be parsed (or for --date=raw, \"0 +0000\").\nBut I do not think we hit that code path at all here.\n\nIt looks like split_ident_line notices the bogus date and returns NULL\nfor s.date_begin. Then format_person_part skips the placeholder, since\nit knows we have nothing worth showing.\n\nI think we probably want to do something like:\n\ndiff --git a/pretty.c b/pretty.c\nindex 3c43db5..7214a2c 100644\n--- a/pretty.c\n+++ b/pretty.c\n@@ -732,14 +732,6 @@ static size_t format_person_part(struct strbuf *sb, char part,\n \t\treturn placeholder_len;\n \t}\n \n-\tif (!s.date_begin)\n-\t\tgoto skip;\n-\n-\tif (part == 't') {\t/* date, UNIX timestamp */\n-\t\tstrbuf_add(sb, s.date_begin, s.date_end - s.date_begin);\n-\t\treturn placeholder_len;\n-\t}\n-\n \tswitch (part) {\n \tcase 'd':\t/* date */\n \t\tstrbuf_addstr(sb, show_ident_date(&s, dmode));\n@@ -753,6 +745,9 @@ static size_t format_person_part(struct strbuf *sb, char part,\n \tcase 'i':\t/* date, ISO 8601 */\n \t\tstrbuf_addstr(sb, show_ident_date(&s, DATE_ISO8601));\n \t\treturn placeholder_len;\n+\tcase 't':\t/* date, UNIX timestamp */\n+\t\tstrbuf_addstr(sb, show_ident_date(&s, DATE_RAW));\n+\t\treturn placeholder_len;\n \t}\n \n skip:\n\nto at least make --format date output consistent with the rest of git\n(and to make \"%at\" consistent with \"%ad\" and --date=raw). That still\ndoesn't address Rodrigo's concern, though (we would print \"0 +0000\").\n\nFor that, we would want on top:\n\n 1. Teach split_ident_line to return _something_ for his malformed\n case.\n\n 2. Teach show_ident_line to treat DATE_RAW to truly output raw\n content, even if it is malformed.\n\nI am not sure whether those are a good idea or not. The current code\nprovides some level of sanitization, so that a parser of log output will\nnot get malformed cruft. And DATE_RAW may mean \"show me what is in the\nraw commit, even if it is broken\". Or it may just mean \"show me the date\nin unix timestamp format, because that is easy to parse\".\n\nI'd argue that if somebody really wants the former, they should be using\n\"--pretty=raw\", which will show the raw commit headers, without any\nparsing or fixup at all.\n\n-Peff\n"},{"id":"242972","messageId":"xmqq7g54begk.fsf@gitster.dls.corp.google.com","threadId":"36781","inReplyTo":"20140529161628.GB3763@sigill.intra.peff.net","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-29T18:57:15Z","receivedAt":"2014-05-29T18:57:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ...\n> to at least make --format date output consistent with the rest of git\n> (and to make \"%at\" consistent with \"%ad\" and --date=raw). That still\n> doesn't address Rodrigo's concern, though (we would print \"0 +0000\").\n>\n> For that, we would want on top:\n>\n> 1. Teach split_ident_line to return _something_ for his malformed\n> case.\n>\n> 2. Teach show_ident_line to treat DATE_RAW to truly output raw\n> content, even if it is malformed.\n>\n> I am not sure whether those are a good idea or not. The current code\n> provides some level of sanitization, so that a parser of log output will\n> not get malformed cruft. And DATE_RAW may mean \"show me what is in the\n> raw commit, even if it is broken\". Or it may just mean \"show me the date\n> in unix timestamp format, because that is easy to parse\".\n>\n> I'd argue that if somebody really wants the former, they should be using\n> \"--pretty=raw\", which will show the raw commit headers, without any\n> parsing or fixup at all.\n\nI actually am not very much interested in deciding what to show for\na broken timestamp. An empty string is just as good as any random\ncruft. I agree with you that it would be nice to have one escape\nhatch to let the users see what garbage is recorded, if only for\ndiagnostic purposes, and DATE_RAW may be one good way to do so (but\nI'd rather recommend \"cat-file commit\" for real diagnostics).\n\nI would be more interested to see whatever broken tool that created\nsuch a commit gets fixed. Do we know where it came from?\n"},{"id":"242977","messageId":"20140529194932.GA16665@sigill.intra.peff.net","threadId":"36781","inReplyTo":"xmqq7g54begk.fsf@gitster.dls.corp.google.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-05-29T19:49:32Z","receivedAt":"2014-05-29T19:49:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 29, 2014 at 11:57:15AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > ...\n> > to at least make --format date output consistent with the rest of git\n> > (and to make \"%at\" consistent with \"%ad\" and --date=raw). That still\n> > doesn't address Rodrigo's concern, though (we would print \"0 +0000\").\n> [...]\n> \n> I actually am not very much interested in deciding what to show for\n> a broken timestamp. An empty string is just as good as any random\n> cruft.\n\nI was thinking specifically of the first part I quoted above. We are not\nconsistent between various methods of parsing/printing the date. That\nmay fall into the \"if were doing it from scratch...\" category, though;\nit's possible that people currently using \"--format=%ad\" prefer and\nexpect the empty string to denote a bogus value. I'm OK with leaving it.\n\n> I agree with you that it would be nice to have one escape\n> hatch to let the users see what garbage is recorded, if only for\n> diagnostic purposes, and DATE_RAW may be one good way to do so (but\n> I'd rather recommend \"cat-file commit\" for real diagnostics).\n\nYeah, in case I wasn't clear, I don't actually like DATE_RAW as a way to\ndo that. I'd prefer \"--pretty=raw\" or \"cat-file commit\", which already\nwork.\n\n> I would be more interested to see whatever broken tool that created\n> such a commit gets fixed. Do we know where it came from?\n\nI don't think it has been said yet in the thread. Rodrigo?\n\n-Peff\n"},{"id":"242978","messageId":"CACJZPBs2_htD=zS1K3fOW+DZ323+2+iwupWuyNDArg2XF6Qx5g@mail.gmail.com","threadId":"36781","inReplyTo":"20140529194932.GA16665@sigill.intra.peff.net","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Rodrigo Fernandes","fromEmail":"rtfrodrigo@gmail.com","sentAt":"2014-05-29T19:57:36Z","receivedAt":"2014-05-29T19:57:36Z","isPatch":false,"sender":{"key":"rtfrodrigo@gmail.com","avatar":"https://gravatar.com/avatar/b94cfe8bec4897d79b90f493dea4edf132c4d09b73a19dc2932fcd902f6d38b4?d=mp&s=160"},"body":"Jeff,\nI have no idea what was the tool. The repo is not mine. I found the\nproblem when I was doing some tests and the commit parsing was failing\non that repo.\n\nCumprimentos,\nRodrigo Fernandes\n\n\nOn Thu, May 29, 2014 at 8:49 PM, Jeff King wrote:\n> On Thu, May 29, 2014 at 11:57:15AM -0700, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>>\n>> > ...\n>> > to at least make --format date output consistent with the rest of git\n>> > (and to make \"%at\" consistent with \"%ad\" and --date=raw). That still\n>> > doesn't address Rodrigo's concern, though (we would print \"0 +0000\").\n>> [...]\n>>\n>> I actually am not very much interested in deciding what to show for\n>> a broken timestamp. An empty string is just as good as any random\n>> cruft.\n>\n> I was thinking specifically of the first part I quoted above. We are not\n> consistent between various methods of parsing/printing the date. That\n> may fall into the \"if were doing it from scratch...\" category, though;\n> it's possible that people currently using \"--format=%ad\" prefer and\n> expect the empty string to denote a bogus value. I'm OK with leaving it.\n>\n>> I agree with you that it would be nice to have one escape\n>> hatch to let the users see what garbage is recorded, if only for\n>> diagnostic purposes, and DATE_RAW may be one good way to do so (but\n>> I'd rather recommend \"cat-file commit\" for real diagnostics).\n>\n> Yeah, in case I wasn't clear, I don't actually like DATE_RAW as a way to\n> do that. I'd prefer \"--pretty=raw\" or \"cat-file commit\", which already\n> work.\n>\n>> I would be more interested to see whatever broken tool that created\n>> such a commit gets fixed. Do we know where it came from?\n>\n> I don't think it has been said yet in the thread. Rodrigo?\n>\n> -Peff\n"},{"id":"243007","messageId":"CACJZPBtJZ+gDvtHnRwi8JOO7rFAg=pPBvEQ=-FwKnp9Gr+FStw@mail.gmail.com","threadId":"36781","inReplyTo":"CACJZPBs2_htD=zS1K3fOW+DZ323+2+iwupWuyNDArg2XF6Qx5g@mail.gmail.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Rodrigo Fernandes","fromEmail":"rtfrodrigo@gmail.com","sentAt":"2014-05-30T08:08:57Z","receivedAt":"2014-05-30T08:08:57Z","isPatch":false,"sender":{"key":"rtfrodrigo@gmail.com","avatar":"https://gravatar.com/avatar/b94cfe8bec4897d79b90f493dea4edf132c4d09b73a19dc2932fcd902f6d38b4?d=mp&s=160"},"body":"Jeff,\nDo you have any idea how does github understand that is a bug and\nfixes it automatically?\n(I'm saying this because on Github the date is correct).\nCumprimentos,\nRodrigo Fernandes\n\n\nOn Thu, May 29, 2014 at 8:57 PM, Rodrigo Fernandes wrote:\n> Jeff,\n> I have no idea what was the tool. The repo is not mine. I found the\n> problem when I was doing some tests and the commit parsing was failing\n> on that repo.\n>\n> Cumprimentos,\n> Rodrigo Fernandes\n>\n>\n> On Thu, May 29, 2014 at 8:49 PM, Jeff King wrote:\n>> On Thu, May 29, 2014 at 11:57:15AM -0700, Junio C Hamano wrote:\n>>\n>>> Jeff King writes:\n>>>\n>>> > ...\n>>> > to at least make --format date output consistent with the rest of git\n>>> > (and to make \"%at\" consistent with \"%ad\" and --date=raw). That still\n>>> > doesn't address Rodrigo's concern, though (we would print \"0 +0000\").\n>>> [...]\n>>>\n>>> I actually am not very much interested in deciding what to show for\n>>> a broken timestamp. An empty string is just as good as any random\n>>> cruft.\n>>\n>> I was thinking specifically of the first part I quoted above. We are not\n>> consistent between various methods of parsing/printing the date. That\n>> may fall into the \"if were doing it from scratch...\" category, though;\n>> it's possible that people currently using \"--format=%ad\" prefer and\n>> expect the empty string to denote a bogus value. I'm OK with leaving it.\n>>\n>>> I agree with you that it would be nice to have one escape\n>>> hatch to let the users see what garbage is recorded, if only for\n>>> diagnostic purposes, and DATE_RAW may be one good way to do so (but\n>>> I'd rather recommend \"cat-file commit\" for real diagnostics).\n>>\n>> Yeah, in case I wasn't clear, I don't actually like DATE_RAW as a way to\n>> do that. I'd prefer \"--pretty=raw\" or \"cat-file commit\", which already\n>> work.\n>>\n>>> I would be more interested to see whatever broken tool that created\n>>> such a commit gets fixed. Do we know where it came from?\n>>\n>> I don't think it has been said yet in the thread. Rodrigo?\n>>\n>> -Peff\n"},{"id":"243175","messageId":"20140603034619.GA18176@sigill.intra.peff.net","threadId":"36781","inReplyTo":"CACJZPBtJZ+gDvtHnRwi8JOO7rFAg=pPBvEQ=-FwKnp9Gr+FStw@mail.gmail.com","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-03T03:46:19Z","receivedAt":"2014-06-03T03:46:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, May 30, 2014 at 09:08:57AM +0100, Rodrigo Fernandes wrote:\n\n> Do you have any idea how does github understand that is a bug and\n> fixes it automatically?\n> (I'm saying this because on Github the date is correct).\n\nI looked into this. The dates you see on GitHub's web UI are actually\nparsed by Rugged/libgit2. The libgit2 parser is slightly more forgiving\nin this instance; if it sees a broken timezone, it will leave the\ntimestamp intact, and only omit the timezone. Whereas git says \"no, it's\nbroken, and the timestamp cannot be trusted\".\n\nI think both are equally valid strategies, and I do not even think it is\na problem that they diverge between the two implementations. I'd be OK\nwith a patch to make git handle errors in each independently, assuming\nit is not too invasive.\n\n-Peff\n"},{"id":"243177","messageId":"20140603062301.GA22149@spirit","threadId":"36781","inReplyTo":"20140603034619.GA18176@sigill.intra.peff.net","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2014-06-03T06:23:02Z","receivedAt":"2014-06-03T06:23:02Z","isPatch":false,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On Mon, Jun 02, 2014 at 11:46:19PM -0400, Jeff King wrote:\n> On Fri, May 30, 2014 at 09:08:57AM +0100, Rodrigo Fernandes wrote:\n> \n> > Do you have any idea how does github understand that is a bug and\n> > fixes it automatically?\n> > (I'm saying this because on Github the date is correct).\n> \n> I looked into this. The dates you see on GitHub's web UI are actually\n> parsed by Rugged/libgit2. The libgit2 parser is slightly more forgiving\n> in this instance; if it sees a broken timezone, it will leave the\n> timestamp intact, and only omit the timezone. Whereas git says \"no, it's\n> broken, and the timestamp cannot be trusted\".\n> \n> I think both are equally valid strategies, and I do not even think it is\n> a problem that they diverge between the two implementations. I'd be OK\n> with a patch to make git handle errors in each independently, assuming\n> it is not too invasive.\n\nI think what libgit2 does is more wrong than what git does. It displays\nthe timestamp subtly wrong (off by 7 hours) instead of making it\ncompletely clear that the timestamp is bogus.\n\n-- \nDennis Kaarsemaker \nhttp://twitter.com/seveas\n"},{"id":"243179","messageId":"20140603064526.GB26150@sigill.intra.peff.net","threadId":"36781","inReplyTo":"20140603062301.GA22149@spirit","subject":"Re: [BUG REPORT] Git log pretty date","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-06-03T06:45:26Z","receivedAt":"2014-06-03T06:45:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jun 03, 2014 at 08:23:02AM +0200, Dennis Kaarsemaker wrote:\n\n> On Mon, Jun 02, 2014 at 11:46:19PM -0400, Jeff King wrote:\n> > On Fri, May 30, 2014 at 09:08:57AM +0100, Rodrigo Fernandes wrote:\n> > \n> > > Do you have any idea how does github understand that is a bug and\n> > > fixes it automatically?\n> > > (I'm saying this because on Github the date is correct).\n> > \n> > I looked into this. The dates you see on GitHub's web UI are actually\n> > parsed by Rugged/libgit2. The libgit2 parser is slightly more forgiving\n> > in this instance; if it sees a broken timezone, it will leave the\n> > timestamp intact, and only omit the timezone. Whereas git says \"no, it's\n> > broken, and the timestamp cannot be trusted\".\n> > \n> > I think both are equally valid strategies, and I do not even think it is\n> > a problem that they diverge between the two implementations. I'd be OK\n> > with a patch to make git handle errors in each independently, assuming\n> > it is not too invasive.\n> \n> I think what libgit2 does is more wrong than what git does. It displays\n> the timestamp subtly wrong (off by 7 hours) instead of making it\n> completely clear that the timestamp is bogus.\n\nI'm not sure what you mean. The timestamp is in UTC seconds-since-epoch,\nand does not depend on the timezone. The timezone only indicates the\nauthor's local time when the commit was made.\n\nWhether the latter is relevant depends on the date format you are\nshowing (i.e., if you are showing it in the author's timezone, it\nmatters; for --date=local or --date=relative, it would not).\n\nSo I do not think libgit2 is at fault for parsing them separately; it\ndoes not know how the result will be presented. What GitHub shows is\nwrong, as it tries to put the timestamp into the author's timezone\n(which it doesn't know). But in practice it turns out be more useful,\nbecause we show relative dates for recent things (so \"8 hours ago\" is\nactually accurate and does not care about the timestamp). For distant\nthings, time zone effects become less important (we show \"Oct 29, 2010\";\nit may have actually been Oct 30 or Oct 28 in the author's zone, but\nit's really not that important anymore).\n\nThose comments are just on the two strategies. As far as\nimplementations, it looks like libgit2 somehow parses this commit as\n+0700, which is odd. I'd expect it to fall back to +0000. I didn't dig\nfurther.\n\n-Peff\n"}]}