{"thread":{"id":"37947","subject":"Bug: git log showing nothing when using --since and --until flags with specific dates","startedAt":"2014-11-13T00:27:06Z","lastAt":"2014-11-14T22:15:19Z","messageCount":11,"participants":["Colin Smith","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251785","messageId":"CAPLyDLo+-SebLvHxVKT7RAiER2c8HdeZQUg7_DGrpER1h-BPQA@mail.gmail.com","threadId":"37947","inReplyTo":null,"subject":"Bug: git log showing nothing when using --since and --until flags with specific dates","fromName":"Colin Smith","fromEmail":"colin.webdev@gmail.com","sentAt":"2014-11-13T00:27:06Z","receivedAt":"2014-11-13T00:27:06Z","isPatch":false,"sender":{"key":"colin.webdev@gmail.com","avatar":null},"body":"Hi all,\n\nApologies if this has already been raised or PEBCAK, but I've noticed\na bug where git log with certain date ranges breaks things. It appears\nto be any --since date with a --until date in the future between\n2014-12-01 and 2014-12-09. Dates from 2014-12-10 appear to work, and\nso does the date 2015-12-01.\n\nTested with the following versions:\n\ngit version 2.2.0.rc1.18.gf6f61cb on Ubuntu\n\ngit version 2.0.1 on whatever the latest version of OS X is.\n\nTo reproduce, on a git repo with a recent enough change to view a\ncheckin after October 1 2014, run 'git log --since=2014-10-01\n--until=2014-12-02' - no errors or anything to indicate the command\nfailed are shown, now run 'git log --since=2014-10-01\n--until=2014-12-10'.\n\nBtw, the mail daemon appears to reject emails with '550 5.7.1\nContent-Policy reject msg: The message contains HTML subpart,\ntherefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is\naccepted.! BF:; S1752168AbaKMAGd' - makes reporting bugs a\nbit of a hassle...\n\n\nCheers,\n\n\n\nColin Smith\n"},{"id":"251794","messageId":"20141113093606.GC8329@peff.net","threadId":"37947","inReplyTo":"CAPLyDLo+-SebLvHxVKT7RAiER2c8HdeZQUg7_DGrpER1h-BPQA@mail.gmail.com","subject":"Re: Bug: git log showing nothing when using --since and --until flags with specific dates","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T09:36:06Z","receivedAt":"2014-11-13T09:36:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 11:27:06AM +1100, Colin Smith wrote:\n\n> Apologies if this has already been raised or PEBCAK, but I've noticed\n> a bug where git log with certain date ranges breaks things. It appears\n> to be any --since date with a --until date in the future between\n> 2014-12-01 and 2014-12-09. Dates from 2014-12-10 appear to work, and\n> so does the date 2015-12-01.\n\nUgh. Approxidate strikes again:\n\n for i in 2014-11-01 2013-12-01 2014-12-01; do\n ./test-date approxidate $i\n done\n\nproduces:\n\n 2014-11-01 -> 2014-11-01 09:35:19 +0000\n 2013-12-01 -> 2013-12-01 09:35:19 +0000\n 2014-12-01 -> 2014-01-12 09:35:19 +0000\n\nThe first two are right, but the fourth one is not. It's probably\nsomething simple and stupid.\n\n-Peff\n"},{"id":"251799","messageId":"20141113110325.GD8329@peff.net","threadId":"37947","inReplyTo":"20141113093606.GC8329@peff.net","subject":"[PATCH 0/2] approxidate and future ISO-like times","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T11:03:25Z","receivedAt":"2014-11-13T11:03:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 04:36:06AM -0500, Jeff King wrote:\n\n> On Thu, Nov 13, 2014 at 11:27:06AM +1100, Colin Smith wrote:\n> \n> > Apologies if this has already been raised or PEBCAK, but I've noticed\n> > a bug where git log with certain date ranges breaks things. It appears\n> > to be any --since date with a --until date in the future between\n> > 2014-12-01 and 2014-12-09. Dates from 2014-12-10 appear to work, and\n> > so does the date 2015-12-01.\n> \n> Ugh. Approxidate strikes again:\n> \n> for i in 2014-11-01 2013-12-01 2014-12-01; do\n> ./test-date approxidate $i\n> done\n> \n> produces:\n> \n> 2014-11-01 -> 2014-11-01 09:35:19 +0000\n> 2013-12-01 -> 2013-12-01 09:35:19 +0000\n> 2014-12-01 -> 2014-01-12 09:35:19 +0000\n> \n> The first two are right, but the fourth one is not. It's probably\n> something simple and stupid.\n\nLess simple and stupid than I thought, but I think I have a fix. It is\nnot about December specifically, but about the date being in the future.\nThe first patch is a cleanup to help us more accurately test the bug;\nthe interesting bits are in the second one.\n\n [1/2]: pass TIME_DATE_NOW to approxidate future-check\n [2/2]: approxidate: allow ISO-like dates far in the future\n\n-Peff\n"},{"id":"251802","messageId":"20141113110452.GA4386@peff.net","threadId":"37947","inReplyTo":"20141113110325.GD8329@peff.net","subject":"[PATCH 1/2] pass TIME_DATE_NOW to approxidate future-check","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T11:04:52Z","receivedAt":"2014-11-13T11:04:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The approxidate functions accept an extra \"now\" parameter to\navoid calling time() themselves. We use this in our test\nsuite to make sure we have a consistent time for computing\nrelative dates. However, deep in the bowels of approxidate,\nwe also call time() to check whether possible dates are far\nin the future. Let's make sure that the \"now\" override makes\nit to that spot, too, so we can consistently test that\nfeature.\n\nSigned-off-by: Jeff King \n---\nThis code path also gets called from the more-strict parse_date (which\ndoes not know about the current time). This continues to call time()\ndynamically, but it is not clear to me if that ever actually matters in\npractice.\n\n date.c | 17 ++++++++++-------\n 1 file changed, 10 insertions(+), 7 deletions(-)\n\ndiff --git a/date.c b/date.c\nindex 59dfe57..e1a4d49 100644\n--- a/date.c\n+++ b/date.c\n@@ -405,9 +405,9 @@ static int is_date(int year, int month, int day, struct tm *now_tm, time_t now,\n \treturn 0;\n }\n \n-static int match_multi_number(unsigned long num, char c, const char *date, char *end, struct tm *tm)\n+static int match_multi_number(unsigned long num, char c, const char *date,\n+\t\t\t char *end, struct tm *tm, time_t now)\n {\n-\ttime_t now;\n \tstruct tm now_tm;\n \tstruct tm *refuse_future;\n \tlong num2, num3;\n@@ -433,7 +433,8 @@ static int match_multi_number(unsigned long num, char c, const char *date, char\n \tcase '-':\n \tcase '/':\n \tcase '.':\n-\t\tnow = time(NULL);\n+\t\tif (!now)\n+\t\t\tnow = time(NULL);\n \t\trefuse_future = NULL;\n \t\tif (gmtime_r(&now, &now_tm))\n \t\t\trefuse_future = &now_tm;\n@@ -513,7 +514,7 @@ static int match_digit(const char *date, struct tm *tm, int *offset, int *tm_gmt\n \tcase '/':\n \tcase '-':\n \t\tif (isdigit(end[1])) {\n-\t\t\tint match = match_multi_number(num, *end, date, end, tm);\n+\t\t\tint match = match_multi_number(num, *end, date, end, tm, 0);\n \t\t\tif (match)\n \t\t\t\treturn match;\n \t\t}\n@@ -1013,7 +1014,8 @@ static const char *approxidate_alpha(const char *date, struct tm *tm, struct tm\n \treturn end;\n }\n \n-static const char *approxidate_digit(const char *date, struct tm *tm, int *num)\n+static const char *approxidate_digit(const char *date, struct tm *tm, int *num,\n+\t\t\t\t time_t now)\n {\n \tchar *end;\n \tunsigned long number = strtoul(date, &end, 10);\n@@ -1024,7 +1026,8 @@ static const char *approxidate_digit(const char *date, struct tm *tm, int *num)\n \tcase '/':\n \tcase '-':\n \t\tif (isdigit(end[1])) {\n-\t\t\tint match = match_multi_number(number, *end, date, end, tm);\n+\t\t\tint match = match_multi_number(number, *end, date, end,\n+\t\t\t\t\t\t tm, now);\n \t\t\tif (match)\n \t\t\t\treturn date + match;\n \t\t}\n@@ -1087,7 +1090,7 @@ static unsigned long approxidate_str(const char *date,\n \t\tdate++;\n \t\tif (isdigit(c)) {\n \t\t\tpending_number(&tm, &number);\n-\t\t\tdate = approxidate_digit(date-1, &tm, &number);\n+\t\t\tdate = approxidate_digit(date-1, &tm, &number, time_sec);\n \t\t\ttouched = 1;\n \t\t\tcontinue;\n \t\t}\n-- \n2.1.2.596.g7379948\n"},{"id":"251803","messageId":"20141113110722.GB4386@peff.net","threadId":"37947","inReplyTo":"20141113110325.GD8329@peff.net","subject":"[PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T11:07:23Z","receivedAt":"2014-11-13T11:07:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"When we are parsing approxidate strings and we find three\nnumbers separate by one of \":/-.\", we guess that it may be a\ndate. We feed the numbers to match_multi_number, which\nchecks whether it makes sense as a date in various orderings\n(e.g., dd/mm/yy or mm/dd/yy, etc).\n\nOne of the checks we do is to see whether it is a date more\nthan 10 days in the future. This was added in 38035cf (date\nparsing: be friendlier to our European friends.,\n2006-04-05), and lets us guess that if it is currently April\n2014, then \"10/03/2014\" is probably March 10th, not October\n3rd.\n\nThis has a downside, though; if you want to be overly\ngenerous with your \"--until\" date specification, we may\nwrongly parse \"2014-12-01\" as \"2014-01-12\" (because the\nlatter is an in-the-past date). If the year is a future year\n(i.e., both are future dates), it gets even weirder. Due to\nthe vagaries of approxidate, months _after_ the current date\n(no matter the year) get flipped, but ones before do not.\n\nThis patch drops the \"in the future\" check for dates of this\nform, letting us treat them always as yyyy-mm-dd, even if\nthey are in the future. This does not affect the normal\ndd/mm/yyyy versus mm/dd/yyyy lookup, because this code path\nonly kicks in when the first number is greater than 70\n(i.e., it must be a year, and cannot be either a date or a\nmonth).\n\nThe one possible casualty is that \"yyyy-dd-mm\" is less\nlikely to be chosen over \"yyyy-mm-dd\". That's probably OK,\nthough because:\n\n 1. The difference happens only when the date is in the\n future. Already we prefer yyyy-mm-dd for dates in the\n past.\n\n 2. It's unclear whether anybody even uses yyyy-dd-mm\n regularly. It does not appear in lists of common date\n formats in Wikipedia[1,2].\n\n 3. Even if (2) is wrong, it is better to prefer ISO-like\n dates, as that is consistent with what we use elsewhere\n in git.\n\n[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country\n[2] http://en.wikipedia.org/wiki/Calendar_date\n\nReported-by: Colin Smith \nSigned-off-by: Jeff King \n---\nI did not single out \"yyyy-mm-dd\" here versus \"yyyy/mm/dd\"; the change\napplies no matter which separator is used. If we wanted to be more\nconservative, we could apply it only to the more ISO-looking form with\ndashes, but I tend to think the reasoning makes sense no matter which\nseparate you use (i.e., I do not think any variant with year then day is\nin common use).\n\n date.c | 29 ++++++++++++++++-------------\n t/t0006-date.sh | 3 +++\n 2 files changed, 19 insertions(+), 13 deletions(-)\n\ndiff --git a/date.c b/date.c\nindex e1a4d49..b9eecfb 100644\n--- a/date.c\n+++ b/date.c\n@@ -363,7 +363,8 @@ static int match_alpha(const char *date, struct tm *tm, int *offset)\n \treturn skip_alpha(date);\n }\n \n-static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, struct tm *tm)\n+static int is_date(int year, int month, int day, struct tm *now_tm, time_t now,\n+\t\t struct tm *tm, int allow_future)\n {\n \tif (month > 0 && month < 13 && day > 0 && day < 32) {\n \t\tstruct tm check = *tm;\n@@ -388,14 +389,16 @@ static int is_date(int year, int month, int day, struct tm *now_tm, time_t now,\n \t\tif (!now_tm)\n \t\t\treturn 1;\n \n-\t\tspecified = tm_to_time_t(r);\n+\t\tif (!allow_future) {\n+\t\t\tspecified = tm_to_time_t(r);\n \n-\t\t/* Be it commit time or author time, it does not make\n-\t\t * sense to specify timestamp way into the future. Make\n-\t\t * sure it is not later than ten days from now...\n-\t\t */\n-\t\tif ((specified != -1) && (now + 10*24*3600 < specified))\n-\t\t\treturn 0;\n+\t\t\t/* Be it commit time or author time, it does not make\n+\t\t\t * sense to specify timestamp way into the future. Make\n+\t\t\t * sure it is not later than ten days from now...\n+\t\t\t */\n+\t\t\tif ((specified != -1) && (now + 10*24*3600 < specified))\n+\t\t\t\treturn 0;\n+\t\t}\n \t\ttm->tm_mon = r->tm_mon;\n \t\ttm->tm_mday = r->tm_mday;\n \t\tif (year != -1)\n@@ -441,10 +444,10 @@ static int match_multi_number(unsigned long num, char c, const char *date,\n \n \t\tif (num > 70) {\n \t\t\t/* yyyy-mm-dd? */\n-\t\t\tif (is_date(num, num2, num3, refuse_future, now, tm))\n+\t\t\tif (is_date(num, num2, num3, refuse_future, now, tm, 1))\n \t\t\t\tbreak;\n \t\t\t/* yyyy-dd-mm? */\n-\t\t\tif (is_date(num, num3, num2, refuse_future, now, tm))\n+\t\t\tif (is_date(num, num3, num2, refuse_future, now, tm, 1))\n \t\t\t\tbreak;\n \t\t}\n \t\t/* Our eastern European friends say dd.mm.yy[yy]\n@@ -452,14 +455,14 @@ static int match_multi_number(unsigned long num, char c, const char *date,\n \t\t * mm/dd/yy[yy] form only when separator is not '.'\n \t\t */\n \t\tif (c != '.' &&\n-\t\t is_date(num3, num, num2, refuse_future, now, tm))\n+\t\t is_date(num3, num, num2, refuse_future, now, tm, 0))\n \t\t\tbreak;\n \t\t/* European dd.mm.yy[yy] or funny US dd/mm/yy[yy] */\n-\t\tif (is_date(num3, num2, num, refuse_future, now, tm))\n+\t\tif (is_date(num3, num2, num, refuse_future, now, tm, 0))\n \t\t\tbreak;\n \t\t/* Funny European mm.dd.yy */\n \t\tif (c == '.' &&\n-\t\t is_date(num3, num, num2, refuse_future, now, tm))\n+\t\t is_date(num3, num, num2, refuse_future, now, tm, 0))\n \t\t\tbreak;\n \t\treturn 0;\n \t}\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex e53cf6d..fac0986 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -82,4 +82,7 @@ check_approxidate 'Jun 6, 5AM' '2009-06-06 05:00:00'\n check_approxidate '5AM Jun 6' '2009-06-06 05:00:00'\n check_approxidate '6AM, June 7, 2009' '2009-06-07 06:00:00'\n \n+check_approxidate '2008-12-01' '2008-12-01 19:20:00'\n+check_approxidate '2009-12-01' '2009-12-01 19:20:00'\n+\n test_done\n-- \n2.1.2.596.g7379948\n"},{"id":"251852","messageId":"xmqqr3x6ztyl.fsf@gitster.dls.corp.google.com","threadId":"37947","inReplyTo":"20141113110722.GB4386@peff.net","subject":"Re: [PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-13T21:11:46Z","receivedAt":"2014-11-13T21:11:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> \t\tif (c != '.' &&\n> -\t\t is_date(num3, num, num2, refuse_future, now, tm))\n> +\t\t is_date(num3, num, num2, refuse_future, now, tm, 0))\n> \t\t\tbreak;\n\nDoesn't the new argument '0', which is \"allow-future\", look somewhat\nstrange when we are already passing refuse_future?\n"},{"id":"251858","messageId":"20141113213647.GB7563@peff.net","threadId":"37947","inReplyTo":"xmqqr3x6ztyl.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T21:36:48Z","receivedAt":"2014-11-13T21:36:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 01:11:46PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > \t\tif (c != '.' &&\n> > -\t\t is_date(num3, num, num2, refuse_future, now, tm))\n> > +\t\t is_date(num3, num, num2, refuse_future, now, tm, 0))\n> > \t\t\tbreak;\n> \n> Doesn't the new argument '0', which is \"allow-future\", look somewhat\n> strange when we are already passing refuse_future?\n\nTo be honest, I had trouble figuring out what the name \"refuse_future\"\nreally meant. We do skip the future check, but it also means that\nis_date will munge the \"struct tm\" directly, even if we do not find a\nvalid date. That worried me a bit.\n\nBut yeah, in theory, the callers I wanted to tweak can just pass in a\nNULL refuse_future.\n\n-Peff\n"},{"id":"251863","messageId":"20141113214330.GA10653@peff.net","threadId":"37947","inReplyTo":"20141113213647.GB7563@peff.net","subject":"Re: [PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T21:43:31Z","receivedAt":"2014-11-13T21:43:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 04:36:47PM -0500, Jeff King wrote:\n\n> On Thu, Nov 13, 2014 at 01:11:46PM -0800, Junio C Hamano wrote:\n> \n> > Jeff King writes:\n> > \n> > > \t\tif (c != '.' &&\n> > > -\t\t is_date(num3, num, num2, refuse_future, now, tm))\n> > > +\t\t is_date(num3, num, num2, refuse_future, now, tm, 0))\n> > > \t\t\tbreak;\n> > \n> > Doesn't the new argument '0', which is \"allow-future\", look somewhat\n> > strange when we are already passing refuse_future?\n> \n> To be honest, I had trouble figuring out what the name \"refuse_future\"\n> really meant. We do skip the future check, but it also means that\n> is_date will munge the \"struct tm\" directly, even if we do not find a\n> valid date. That worried me a bit.\n> \n> But yeah, in theory, the callers I wanted to tweak can just pass in a\n> NULL refuse_future.\n\nSo here's what the patch looks like just using refuse_future.\n\nIt's definitely nicer to read, and it passes the tests. But I am still\nconcerned there is some unknown case that is impacted by us half-filling\nout the tm_mon and tm_mday fields of the \"struct tm\" in the first half\nof is_date.\n\n-- >8 --\nSubject: approxidate: allow ISO-like dates far in the future\n\nWhen we are parsing approxidate strings and we find three\nnumbers separate by one of \":/-.\", we guess that it may be a\ndate. We feed the numbers to match_multi_number, which\nchecks whether it makes sense as a date in various orderings\n(e.g., dd/mm/yy or mm/dd/yy, etc).\n\nOne of the checks we do is to see whether it is a date more\nthan 10 days in the future. This was added in 38035cf (date\nparsing: be friendlier to our European friends.,\n2006-04-05), and lets us guess that if it is currently April\n2014, then \"10/03/2014\" is probably March 10th, not October\n3rd.\n\nThis has a downside, though; if you want to be overly\ngenerous with your \"--until\" date specification, we may\nwrongly parse \"2014-12-01\" as \"2014-01-12\" (because the\nlatter is an in-the-past date). If the year is a future year\n(i.e., both are future dates), it gets even weirder. Due to\nthe vagaries of approxidate, months _after_ the current date\n(no matter the year) get flipped, but ones before do not.\n\nThis patch drops the \"in the future\" check for dates of this\nform, letting us treat them always as yyyy-mm-dd, even if\nthey are in the future. This does not affect the normal\ndd/mm/yyyy versus mm/dd/yyyy lookup, because this code path\nonly kicks in when the first number is greater than 70\n(i.e., it must be a year, and cannot be either a date or a\nmonth).\n\nThe one possible casualty is that \"yyyy-dd-mm\" is less\nlikely to be chosen over \"yyyy-mm-dd\". That's probably OK,\nthough because:\n\n 1. The difference happens only when the date is in the\n future. Already we prefer yyyy-mm-dd for dates in the\n past.\n\n 2. It's unclear whether anybody even uses yyyy-dd-mm\n regularly. It does not appear in lists of common date\n formats in Wikipedia[1,2].\n\n 3. Even if (2) is wrong, it is better to prefer ISO-like\n dates, as that is consistent with what we use elsewhere\n in git.\n\n[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country\n[2] http://en.wikipedia.org/wiki/Calendar_date\n\nSigned-off-by: Jeff King \n---\n date.c | 4 ++--\n t/t0006-date.sh | 3 +++\n 2 files changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/date.c b/date.c\nindex e1a4d49..3eba2df 100644\n--- a/date.c\n+++ b/date.c\n@@ -441,10 +441,10 @@ static int match_multi_number(unsigned long num, char c, const char *date,\n \n \t\tif (num > 70) {\n \t\t\t/* yyyy-mm-dd? */\n-\t\t\tif (is_date(num, num2, num3, refuse_future, now, tm))\n+\t\t\tif (is_date(num, num2, num3, NULL, now, tm))\n \t\t\t\tbreak;\n \t\t\t/* yyyy-dd-mm? */\n-\t\t\tif (is_date(num, num3, num2, refuse_future, now, tm))\n+\t\t\tif (is_date(num, num3, num2, NULL, now, tm))\n \t\t\t\tbreak;\n \t\t}\n \t\t/* Our eastern European friends say dd.mm.yy[yy]\ndiff --git a/t/t0006-date.sh b/t/t0006-date.sh\nindex e53cf6d..fac0986 100755\n--- a/t/t0006-date.sh\n+++ b/t/t0006-date.sh\n@@ -82,4 +82,7 @@ check_approxidate 'Jun 6, 5AM' '2009-06-06 05:00:00'\n check_approxidate '5AM Jun 6' '2009-06-06 05:00:00'\n check_approxidate '6AM, June 7, 2009' '2009-06-07 06:00:00'\n \n+check_approxidate '2008-12-01' '2008-12-01 19:20:00'\n+check_approxidate '2009-12-01' '2009-12-01 19:20:00'\n+\n test_done\n-- \n2.1.2.596.g7379948\n"},{"id":"251867","messageId":"xmqqtx22ybga.fsf@gitster.dls.corp.google.com","threadId":"37947","inReplyTo":"20141113213647.GB7563@peff.net","subject":"Re: [PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-13T22:36:53Z","receivedAt":"2014-11-13T22:36:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Nov 13, 2014 at 01:11:46PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > \t\tif (c != '.' &&\n>> > -\t\t is_date(num3, num, num2, refuse_future, now, tm))\n>> > +\t\t is_date(num3, num, num2, refuse_future, now, tm, 0))\n>> > \t\t\tbreak;\n>> \n>> Doesn't the new argument '0', which is \"allow-future\", look somewhat\n>> strange when we are already passing refuse_future?\n>\n> To be honest, I had trouble figuring out what the name \"refuse_future\"\n> really meant. We do skip the future check, but it also means that\n> is_date will munge the \"struct tm\" directly, even if we do not find a\n> valid date. That worried me a bit.\n\nAh, OK. That worries me, too, now you mention it. I just didn't\nsee it myself ;-)\n>\n> But yeah, in theory, the callers I wanted to tweak can just pass in a\n> NULL refuse_future.\n>\n> -Peff\n"},{"id":"251876","messageId":"20141114084725.GA16030@peff.net","threadId":"37947","inReplyTo":"CA+EOSBn0-ZFOPaeU92a0YWPW_S9kenoRUjJMp-Nhm-azftrEfA@mail.gmail.com","subject":"Re: [PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-14T08:47:25Z","receivedAt":"2014-11-14T08:47:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 14, 2014 at 06:46:19AM +0100, Elia Pinto wrote:\n\n> > [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country\n> > [2] http://en.wikipedia.org/wiki/Calendar_date\n> \n> Isn't not so good to refer to external resources in a commit message ?\n\nIt is not good to omit any explanation and just include a link, like:\n\n Fixes the bug reported in http://...\n\nbecause people who are reading \"git log\" have to follow that link to\neven see what you are talking about (and the link might go away, or they\nmight not have access at the time).\n\nIt is fine, and even desirable, to summarize the relevant content of a\nresource and provide a link for people who want to dig further. In this\ncase, I am saying \"Wikipedia claims that nobody uses this format\" and\nbacking it up with a link to indicate which pages I checked. You do not\nhave to follow the link to know what I am saying, but if you want to\ndig deeper, you at least know where I left off my research.\n\nDoes that make sense?\n\n-Peff\n"},{"id":"251919","messageId":"xmqqtx211lag.fsf@gitster.dls.corp.google.com","threadId":"37947","inReplyTo":"20141114084725.GA16030@peff.net","subject":"Re: [PATCH 2/2] approxidate: allow ISO-like dates far in the future","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-14T22:15:19Z","receivedAt":"2014-11-14T22:15:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Nov 14, 2014 at 06:46:19AM +0100, Elia Pinto wrote:\n>\n>> > [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country\n>> > [2] http://en.wikipedia.org/wiki/Calendar_date\n>> \n>> Isn't not so good to refer to external resources in a commit message ?\n>\n> It is not good to omit any explanation and just include a link, like:\n>\n> Fixes the bug reported in http://...\n>\n> because people who are reading \"git log\" have to follow that link to\n> even see what you are talking about (and the link might go away, or they\n> might not have access at the time).\n>\n> It is fine, and even desirable, to summarize the relevant content of a\n> resource and provide a link for people who want to dig further. In this\n> case, I am saying \"Wikipedia claims that nobody uses this format\" and\n> backing it up with a link to indicate which pages I checked. You do not\n> have to follow the link to know what I am saying, but if you want to\n> dig deeper, you at least know where I left off my research.\n>\n> Does that make sense?\n\nWhat you wrote matches the level of details I have been trying to\nstick to when writing references in my own log messages and when\ntweaking others' log messages.\n\nThanks.\n"}]}