{"thread":{"id":"32773","subject":"[BUG] incorrect search result returned when using git log with a future date parameter","startedAt":"2013-01-30T11:28:04Z","lastAt":"2013-01-30T11:28:04Z","messageCount":1,"participants":["Caspar Zhang"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"208255","messageId":"510903C4.6060809@casparzhang.com","threadId":"32773","inReplyTo":null,"subject":"[BUG] incorrect search result returned when using git log with a future date parameter","fromName":"Caspar Zhang","fromEmail":"caspar@casparzhang.com","sentAt":"2013-01-30T11:28:04Z","receivedAt":"2013-01-30T11:28:04Z","isPatch":false,"sender":{"key":"caspar@casparzhang.com","avatar":null},"body":"Hi there,\n\nwhen I'm using the commit limit option `--before/--until` when doing \n`git log` search, I meet a bug when the upper-bound date is 10days later \nin the future. Here is an example:\n\n$ date +%F\n2013-01-30\n$ git log --oneline --since=2013-01-01 --until=2013-02-01\n<several git log entry from 2013-01-01 to 2013-01-30 printed>\n$ git log --oneline --since=2013-01-01 --until=2013-02-13\n<null>\n\nI debugged into the problem with ./test-date program in git source tree, \ngot:\n\n$ ./test-date approxidate 2013-02-01\n2013-02-01 -> 2013-02-01 10:47:13 +0000   // correctly parsed\n$ ./test-date approxidate 2013-02-13\n2013-02-13 -> 2013-01-02 10:47:20 +0000   // incorrectly parsed\n\nWhen looking into the codes of date.c, in is_date() function, I found:\n\n  382         /* Be it commit time or author time, it does not make\n  383          * sense to specify timestamp way into the future.  Make\n  384          * sure it is not later than ten days from now...\n  385          */\n  386         if (now + 10*24*3600 < specified)\n  387                  return 0;\n  388         tm->tm_mon = r->tm_mon;\n  389         tm->tm_mday = r->tm_mday;\n  390         if (year != -1)\n  391                 tm->tm_year = r->tm_year;\n  392         return 1;\n\nIf I comment Line 386 & 387 out, the parsing works correctly. So I guess \nhere is the cause of the problem.\n\nThen I checked the git history, the change was introduced in commit \n38035cf4 by Junio C Hamano (cc-ed):\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ncommit 38035cf4a51c48cccf6c5e3977130261bc0c03a7\nAuthor: Junio C Hamano <junkio@cox.net>\nDate:   Wed Apr 5 15:31:12 2006 -0700\n\n     date parsing: be friendlier to our European friends.\n\n     This does three things, only applies to cases where the user\n     manually tries to override the author/commit time by environment\n     variables, with non-ISO, non-2822 format date-string:\n\n      - Refuses to use the interpretation to put the date in the\n        future; recent kernel history has a commit made with\n        10/03/2006 which is recorded as October 3rd.\n\n      - Adds '.' as the possible year-month-date separator.  We\n        learned from our European friends on the #git channel that\n        dd.mm.yyyy is the norm there.\n\n      - When the separator is '.', we prefer dd.mm.yyyy over\n        mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over\n        dd/mm/yy[yy].\n\n     Signed-off-by: Junio C Hamano <junkio@cox.net>\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIt seems like the original commit was going to fix European date style, \nbut it fixed(?) the future date problem as well. However, this part of \nfix is not perfect:\n\n1) it makes date parsing not working correctly. (see my test examples \nabove).\n\nIMO, it should be in another place (maybe in commit.c or somewhere \nelse?) we check if commit date is valid or not, instead of in the date \nparsing function. A date parsing function should parse _all dates with \ncorrectly format_, despite if it's an old date, or the date in the future.\n\n2) from the test example I gave above, in fact the codes don't really \nprevent git from accepting the changes with illegal date, e.g., if there \nis a commit recorded as \"2013-02-13\", it will be parsed to \"2013-01-02\", \nwhich is a legal (old) date, thus, this commit will be accepted, but \nthis is wrong.\n\nMy suggestion is we might need to revert the first part of commit \n38035cf4 since this part of code doesn't work correctly and causes \nproblems; then we should create a new checking mechanism to prevent \nthose \"future date commits\" to be accepted in other functions. I'm not \nable to do the second part since I'm not familiar with git codes yet.. :-(\n\nThoughts?\n\nCaspar\n"}]}