{"thread":{"id":"3797","subject":"[PATCH] parse_date(): fix parsing 03/10/2006","startedAt":"2006-04-05T06:00:04Z","lastAt":"2006-07-14T10:26:07Z","messageCount":8,"participants":["Junio C Hamano","Andrew Morton","Sam Ravnborg","David Woodhouse"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"18363","messageId":"7vodzg4l5n.fsf@assigned-by-dhcp.cox.net","threadId":"3797","inReplyTo":null,"subject":"[PATCH] parse_date(): fix parsing 03/10/2006","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T06:00:04Z","receivedAt":"2006-04-05T06:00:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The comment associated with the date parsing code for three\nnumbers separated with slashes or dashes implied we wanted to\ninterpret using this order:\n\n\tyyyy-mm-dd\n\tyyyy-dd-mm\n\tmm-dd-yy\n\tdd-mm-yy\n\nHowever, the actual code had the last two wrong, and making it\nprefer dd-mm-yy format over mm-dd-yy.\n\nSigned-off-by: Junio C Hamano \n\n---\n * Spotted, thanks to Len Brown and Andrew Morton.\n\n date.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\nf5cd7df6e8322a0b783668b31881ab95a5ce33bd\ndiff --git a/date.c b/date.c\nindex 416ea57..18a0710 100644\n--- a/date.c\n+++ b/date.c\n@@ -257,10 +257,10 @@ static int match_multi_number(unsigned l\n \t\t\t\tbreak;\n \t\t}\n \t\t/* mm/dd/yy ? */\n-\t\tif (is_date(num3, num2, num, tm))\n+\t\tif (is_date(num3, num, num2, tm))\n \t\t\tbreak;\n \t\t/* dd/mm/yy ? */\n-\t\tif (is_date(num3, num, num2, tm))\n+\t\tif (is_date(num3, num2, num, tm))\n \t\t\tbreak;\n \t\treturn 0;\n \t}\n-- \n1.3.0.rc2.g110c\n"},{"id":"18366","messageId":"20060404231606.219a4cc5.akpm@osdl.org","threadId":"3797","inReplyTo":"7vodzg4l5n.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] parse_date(): fix parsing 03/10/2006","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-04-05T06:16:06Z","receivedAt":"2006-04-05T06:16:06Z","isPatch":true,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Junio C Hamano wrote:\n>\n> The comment associated with the date parsing code for three\n> numbers separated with slashes or dashes implied we wanted to\n> interpret using this order:\n> \n> \tyyyy-mm-dd\n> \tyyyy-dd-mm\n> \tmm-dd-yy\n> \tdd-mm-yy\n> \n> However, the actual code had the last two wrong, and making it\n> prefer dd-mm-yy format over mm-dd-yy.\n\nBut there was a second problem. Once the parsing had misbehaved, Len\nmanaged to create a commit which was six months in the future:\n\ncommit 8313524a0d466f451a62709aaedf988d8257b21c\nAuthor: Bob Moore \nDate: Tue Oct 3 00:00:00 2006 -0400\n\n ACPI: ACPICA 20060310\n\nWill your fix prevent that from happening? If not, perhaps some basic\nsanity checking might be appropriate.\n"},{"id":"18368","messageId":"7virpo4jxf.fsf@assigned-by-dhcp.cox.net","threadId":"3797","inReplyTo":"20060404231606.219a4cc5.akpm@osdl.org","subject":"Re: [PATCH] parse_date(): fix parsing 03/10/2006","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T06:26:36Z","receivedAt":"2006-04-05T06:26:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andrew Morton writes:\n\n> But there was a second problem. Once the parsing had misbehaved, Len\n> managed to create a commit which was six months in the future:\n>\n> commit 8313524a0d466f451a62709aaedf988d8257b21c\n> Author: Bob Moore \n> Date: Tue Oct 3 00:00:00 2006 -0400\n>\n> ACPI: ACPICA 20060310\n>\n> Will your fix prevent that from happening? If not, perhaps some basic\n> sanity checking might be appropriate.\n\nYou _might_ get an e-mail to fix kernel problems from yourself\nin the future, in which case you would want to commit with\nfuture author date, like this ;-).\n\nPeople would often deal with dates in the past (way in the past\nwhen talking about importing foreign SCM history), but probably\nit would never make sense to do dates way into the future. I'll\nthink about it.\n"},{"id":"18370","messageId":"20060404234048.0236886e.akpm@osdl.org","threadId":"3797","inReplyTo":"7virpo4jxf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] parse_date(): fix parsing 03/10/2006","fromName":"Andrew Morton","fromEmail":"akpm@osdl.org","sentAt":"2006-04-05T06:40:48Z","receivedAt":"2006-04-05T06:40:48Z","isPatch":true,"sender":{"key":"akpm@osdl.org","avatar":null},"body":"Junio C Hamano wrote:\n>\n> Andrew Morton writes:\n> \n> > But there was a second problem. Once the parsing had misbehaved, Len\n> > managed to create a commit which was six months in the future:\n> >\n> > commit 8313524a0d466f451a62709aaedf988d8257b21c\n> > Author: Bob Moore \n> > Date: Tue Oct 3 00:00:00 2006 -0400\n> >\n> > ACPI: ACPICA 20060310\n> >\n> > Will your fix prevent that from happening? If not, perhaps some basic\n> > sanity checking might be appropriate.\n> \n> You _might_ get an e-mail to fix kernel problems from yourself\n> in the future, in which case you would want to commit with\n> future author date, like this ;-).\n> \n> People would often deal with dates in the past (way in the past\n> when talking about importing foreign SCM history), but probably\n> it would never make sense to do dates way into the future. I'll\n> think about it.\n> \n\nWell it doesn't have to be fatal, of course. Some \"do you really want to\ndo this [y/n]?\" prompt, with a command option to override it. Or simply\nprint a big warning.\n\nWhatever.\n"},{"id":"18407","messageId":"7vlkujzly0.fsf_-_@assigned-by-dhcp.cox.net","threadId":"3797","inReplyTo":"7virpo4jxf.fsf@assigned-by-dhcp.cox.net","subject":"[RFC/PATCH] date parsing: be friendlier to our European friends.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T22:39:35Z","receivedAt":"2006-04-05T22:39:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This does three things, only applies to cases where the user\nmanually tries to override the author/commit time by environment\nvariables, 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\nSigned-off-by: Junio C Hamano \n\n---\n\n * This is more of a RFC than ready-to-be-merged patch.\n Alternative patches and improvements are welcome.\n\n date.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++-----------------\n 1 files changed, 56 insertions(+), 21 deletions(-)\n\nb9065540826426ac0e4959e869ba7e08d1ae65d8\ndiff --git a/date.c b/date.c\nindex 376d25d..034d722 100644\n--- a/date.c\n+++ b/date.c\n@@ -197,26 +197,43 @@ static int match_alpha(const char *date,\n \treturn skip_alpha(date);\n }\n \n-static int is_date(int year, int month, int day, struct tm *tm)\n+static int is_date(int year, int month, int day, struct tm *now_tm, time_t now, struct tm *tm)\n {\n \tif (month > 0 && month < 13 && day > 0 && day < 32) {\n+\t\tstruct tm check = *tm;\n+\t\tstruct tm *r = (now_tm ? &check : tm);\n+\t\ttime_t specified;\n+\n+\t\tr->tm_mon = month - 1;\n+\t\tr->tm_mday = day;\n \t\tif (year == -1) {\n-\t\t\ttm->tm_mon = month-1;\n-\t\t\ttm->tm_mday = day;\n-\t\t\treturn 1;\n+\t\t\tif (!now_tm)\n+\t\t\t\treturn 1;\n+\t\t\tr->tm_year = now_tm->tm_year;\n \t\t}\n-\t\tif (year >= 1970 && year < 2100) {\n-\t\t\tyear -= 1900;\n-\t\t} else if (year > 70 && year < 100) {\n-\t\t\t/* ok */\n-\t\t} else if (year < 38) {\n-\t\t\tyear += 100;\n-\t\t} else\n+\t\telse if (year >= 1970 && year < 2100)\n+\t\t\tr->tm_year = year - 1900;\n+\t\telse if (year > 70 && year < 100)\n+\t\t\tr->tm_year = year;\n+\t\telse if (year < 38)\n+\t\t\tr->tm_year = year + 100;\n+\t\telse\n \t\t\treturn 0;\n+\t\tif (!now_tm)\n+\t\t\treturn 1;\n+\n+\t\tspecified = my_mktime(r);\n \n-\t\ttm->tm_mon = month-1;\n-\t\ttm->tm_mday = day;\n-\t\ttm->tm_year = year;\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 (now + 10*24*3600 < specified)\n+\t\t\treturn 0;\n+\t\ttm->tm_mon = r->tm_mon;\n+\t\ttm->tm_mday = r->tm_mday;\n+\t\tif (year != -1)\n+\t\t\ttm->tm_year = r->tm_year;\n \t\treturn 1;\n \t}\n \treturn 0;\n@@ -224,6 +241,9 @@ static int is_date(int year, int month, \n \n static int match_multi_number(unsigned long num, char c, const char *date, char *end, struct tm *tm)\n {\n+\ttime_t now;\n+\tstruct tm now_tm;\n+\tstruct tm *refuse_future;\n \tlong num2, num3;\n \n \tnum2 = strtol(end+1, &end, 10);\n@@ -246,19 +266,33 @@ static int match_multi_number(unsigned l\n \n \tcase '-':\n \tcase '/':\n+\tcase '.':\n+\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+\n \t\tif (num > 70) {\n \t\t\t/* yyyy-mm-dd? */\n-\t\t\tif (is_date(num, num2, num3, tm))\n+\t\t\tif (is_date(num, num2, num3, refuse_future, now, tm))\n \t\t\t\tbreak;\n \t\t\t/* yyyy-dd-mm? */\n-\t\t\tif (is_date(num, num3, num2, tm))\n+\t\t\tif (is_date(num, num3, num2, refuse_future, now, tm))\n \t\t\t\tbreak;\n \t\t}\n-\t\t/* mm/dd/yy ? */\n-\t\tif (is_date(num3, num, num2, tm))\n+\t\t/* Our eastern European friends say dd.mm.yy[yy]\n+\t\t * is the norm there, so giving precedence to\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\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\t\tbreak;\n-\t\t/* dd/mm/yy ? */\n-\t\tif (is_date(num3, num2, num, tm))\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\tbreak;\n \t\treturn 0;\n \t}\n@@ -288,10 +322,11 @@ static int match_digit(const char *date,\n \t}\n \n \t/*\n-\t * Check for special formats: num[:-/]num[same]num\n+\t * Check for special formats: num[-.:/]num[same]num\n \t */\n \tswitch (*end) {\n \tcase ':':\n+\tcase '.':\n \tcase '/':\n \tcase '-':\n \t\tif (isdigit(end[1])) {\n-- \n1.3.0.rc2.g1b83\n"},{"id":"18408","messageId":"20060405224751.GA10139@mars.ravnborg.org","threadId":"3797","inReplyTo":"7vlkujzly0.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] date parsing: be friendlier to our European friends.","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2006-04-05T22:47:51Z","receivedAt":"2006-04-05T22:47:51Z","isPatch":true,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Wed, Apr 05, 2006 at 03:39:35PM -0700, Junio C Hamano wrote:\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\nI my company we have always used yyyy-mm-dd - this is an ISO standard\nIIRC. The company is European based.\n\nmm/dd/yy has always made my head spin ;-)\n\n\tSam\n"},{"id":"18409","messageId":"7vhd57zl9x.fsf@assigned-by-dhcp.cox.net","threadId":"3797","inReplyTo":"7vlkujzly0.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] date parsing: be friendlier to our European friends.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-05T22:54:02Z","receivedAt":"2006-04-05T22:54:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\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\nBefore the list gets useless comments, the code prefer to accept\nmore sensible and/or unambiguous forms, such as ISO or RFC2822.\nThe issue this addresses is what to do when we get other forms.\n"},{"id":"23813","messageId":"1152872768.3191.58.camel@pmac.infradead.org","threadId":"3797","inReplyTo":"7vhd57zl9x.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC/PATCH] date parsing: be friendlier to our European friends.","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2006-07-14T10:26:07Z","receivedAt":"2006-07-14T10:26:07Z","isPatch":true,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2006-04-05 at 15:54 -0700, Junio C Hamano wrote:\n> Before the list gets useless comments, the code prefer to accept\n> more sensible and/or unambiguous forms, such as ISO or RFC2822.\n> The issue this addresses is what to do when we get other forms.\n\nRejecting them and demanding unambiguous forms is better than silently\ngetting it wrong.\n\n-- \ndwmw2\n"}]}