{"thread":{"id":"27308","subject":"Approxidate with YYYY.MM","startedAt":"2011-05-09T19:02:33Z","lastAt":"2011-05-22T17:10:08Z","messageCount":7,"participants":["Brian Gernhardt","Michael J Gruber","Andreas Ericsson","Victor Engmark","Michael Witten"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"167516","messageId":"CAE5FB52-0F90-4F21-828F-7E40ED596B33@gernhardtsoftware.com","threadId":"27308","inReplyTo":null,"subject":"Approxidate with YYYY.MM","fromName":"Brian Gernhardt","fromEmail":"brian@gernhardtsoftware.com","sentAt":"2011-05-09T19:02:33Z","receivedAt":"2011-05-09T19:02:33Z","isPatch":false,"sender":{"key":"brian@gernhardtsoftware.com","avatar":"https://avatars.githubusercontent.com/u/133455?v=4"},"body":"(This is in response to a discussion on #parrot.)\n\nRakudo (https://github.com/rakudo/rakudo/) uses tags of the form YYYY.MM for their monthly releases. When we were attempting to find the cause of a slowdown, somewhat was trying to find what commits occurred after the 2011.01 release with \"git log --after=2011.01\". His mistake was pointed out but this led to the confusion of why this was parsed as \"May 1 2011\" instead of \"Jan 1 2011\". Shouldn't date.c:match_multi_number() parse something with only two numbers as a beginning of month instead of allowing it to pass through to the generic parsing?\n\nI'm currently nearing finals in school, so lack the time for an RFC patch at the moment.\n\n~~ Brian"},{"id":"167581","messageId":"4DC8DCC2.8050208@drmicha.warpmail.net","threadId":"27308","inReplyTo":"CAE5FB52-0F90-4F21-828F-7E40ED596B33@gernhardtsoftware.com","subject":"Re: Approxidate with YYYY.MM","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-05-10T06:35:46Z","receivedAt":"2011-05-10T06:35:46Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Brian Gernhardt venit, vidit, dixit 09.05.2011 21:02:\n> (This is in response to a discussion on #parrot.)\n> \n> Rakudo (https://github.com/rakudo/rakudo/) uses tags of the form\n> YYYY.MM for their monthly releases. When we were attempting to find\n> the cause of a slowdown, somewhat was trying to find what commits\n> occurred after the 2011.01 release with \"git log --after=2011.01\".\n> His mistake was pointed out but this led to the confusion of why this\n> was parsed as \"May 1 2011\" instead of \"Jan 1 2011\". Shouldn't\n> date.c:match_multi_number() parse something with only two numbers as\n> a beginning of month instead of allowing it to pass through to the\n> generic parsing?\n\nI just don't think there is a format like that. There is dd.mm.[yy]yy\nand apparently also yyyy.mm.dd, but without leading zeros in mm for the\nlatter. Our date parser also takes \".\" for a space so that you don't\nneed to quote a space (\"1.day.ago\"). I can see the logic behind parsing\n2011.01 as January 2011, but it's a stretch from the existing formats:\n\nhttp://en.wikipedia.org/wiki/Calendar_date#Date_format\n\n> I'm currently nearing finals in school, so lack the time for an RFC\n> patch at the moment.\n\nGood luck :)\n\nMichael\n"},{"id":"167583","messageId":"4DC8E129.2020306@op5.se","threadId":"27308","inReplyTo":"4DC8DCC2.8050208@drmicha.warpmail.net","subject":"Re: Approxidate with YYYY.MM","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-05-10T06:54:33Z","receivedAt":"2011-05-10T06:54:33Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 05/10/2011 08:35 AM, Michael J Gruber wrote:\n> Brian Gernhardt venit, vidit, dixit 09.05.2011 21:02:\n>> (This is in response to a discussion on #parrot.)\n>>\n>> Rakudo (https://github.com/rakudo/rakudo/) uses tags of the form\n>> YYYY.MM for their monthly releases. When we were attempting to find\n>> the cause of a slowdown, somewhat was trying to find what commits\n>> occurred after the 2011.01 release with \"git log --after=2011.01\".\n>> His mistake was pointed out but this led to the confusion of why this\n>> was parsed as \"May 1 2011\" instead of \"Jan 1 2011\". Shouldn't\n>> date.c:match_multi_number() parse something with only two numbers as\n>> a beginning of month instead of allowing it to pass through to the\n>> generic parsing?\n> \n> I just don't think there is a format like that. There is dd.mm.[yy]yy\n> and apparently also yyyy.mm.dd, but without leading zeros in mm for the\n> latter. Our date parser also takes \".\" for a space so that you don't\n> need to quote a space (\"1.day.ago\"). I can see the logic behind parsing\n> 2011.01 as January 2011, but it's a stretch from the existing formats:\n> \n\nIt would be far more logical to parse \"2011-01\" as \"January 2011\" as\nthat's the preferred way to write month-precision dates in most\ncountries that use both the metric system and the gregorian calender.\n\nI've never seen that date-type with dot as a separator, but with the\ndash it's very, very common.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"167584","messageId":"4DC8E451.7090702@drmicha.warpmail.net","threadId":"27308","inReplyTo":"4DC8E129.2020306@op5.se","subject":"Re: Approxidate with YYYY.MM","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-05-10T07:08:01Z","receivedAt":"2011-05-10T07:08:01Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Andreas Ericsson venit, vidit, dixit 10.05.2011 08:54:\n> On 05/10/2011 08:35 AM, Michael J Gruber wrote:\n>> Brian Gernhardt venit, vidit, dixit 09.05.2011 21:02:\n>>> (This is in response to a discussion on #parrot.)\n>>>\n>>> Rakudo (https://github.com/rakudo/rakudo/) uses tags of the form\n>>> YYYY.MM for their monthly releases. When we were attempting to find\n>>> the cause of a slowdown, somewhat was trying to find what commits\n>>> occurred after the 2011.01 release with \"git log --after=2011.01\".\n>>> His mistake was pointed out but this led to the confusion of why this\n>>> was parsed as \"May 1 2011\" instead of \"Jan 1 2011\". Shouldn't\n>>> date.c:match_multi_number() parse something with only two numbers as\n>>> a beginning of month instead of allowing it to pass through to the\n>>> generic parsing?\n>>\n>> I just don't think there is a format like that. There is dd.mm.[yy]yy\n>> and apparently also yyyy.mm.dd, but without leading zeros in mm for the\n>> latter. Our date parser also takes \".\" for a space so that you don't\n>> need to quote a space (\"1.day.ago\"). I can see the logic behind parsing\n>> 2011.01 as January 2011, but it's a stretch from the existing formats:\n>>\n> \n> It would be far more logical to parse \"2011-01\" as \"January 2011\" as\n> that's the preferred way to write month-precision dates in most\n> countries that use both the metric system and the gregorian calender.\n> \n> I've never seen that date-type with dot as a separator, but with the\n> dash it's very, very common.\n> \n\nExactly that's what I wrote. People misuse the dot format probably as\nfrequently as the dash format, in the sense that the use an ordering\nwhich is wrong for the respective separator. We currently parse n.m as\nday n of month m of the current year for certain n only: We parse\n\n31.3. as March 3rd of the current year\n32.3. as May 3rd of 2032\n\n(because May is the current month) which does not make that much sense,\nadmittedly. I would have hoped the latter to be April 1st (current\nyear). I agree that defaulting the month to the current month in the dot\nformat makes no sense, but I think (and I guess we disagree here) that\nit's a matter of garbage in - garbage out. As for turning that garbage\ninto marbles: 32.3. == 1.4. seems more logical to me. Note that for example\n\n2020.9.11 -> 2020-11-09 07:06:16 +0000\n\nwhich means that we *never* parse the Chinese yyyy.mm.dd correctly, not\neven the complete form!\n\nMichael\n"},{"id":"167585","messageId":"4DC8EBD8.50707@terreactive.ch","threadId":"27308","inReplyTo":"964517.31047.1305010481774.JavaMail.trustmail@mail1.terreactive.ch","subject":"Re: Approxidate with YYYY.MM","fromName":"Victor Engmark","fromEmail":"victor.engmark@terreactive.ch","sentAt":"2011-05-10T07:40:08Z","receivedAt":"2011-05-10T07:40:08Z","isPatch":false,"sender":{"key":"victor.engmark@terreactive.ch","avatar":null},"body":"On 05/10/2011 08:54 AM, Andreas Ericsson wrote:\n> On 05/10/2011 08:35 AM, Michael J Gruber wrote:\n>> Brian Gernhardt venit, vidit, dixit 09.05.2011 21:02:\n>>> (This is in response to a discussion on #parrot.)\n>>>\n>>> Rakudo (https://github.com/rakudo/rakudo/) uses tags of the form\n>>> YYYY.MM for their monthly releases. When we were attempting to find\n>>> the cause of a slowdown, somewhat was trying to find what commits\n>>> occurred after the 2011.01 release with \"git log --after=2011.01\".\n>>> His mistake was pointed out but this led to the confusion of why this\n>>> was parsed as \"May 1 2011\" instead of \"Jan 1 2011\". Shouldn't\n>>> date.c:match_multi_number() parse something with only two numbers as\n>>> a beginning of month instead of allowing it to pass through to the\n>>> generic parsing?\n>>\n>> I just don't think there is a format like that. There is dd.mm.[yy]yy\n>> and apparently also yyyy.mm.dd, but without leading zeros in mm for the\n>> latter. Our date parser also takes \".\" for a space so that you don't\n>> need to quote a space (\"1.day.ago\"). I can see the logic behind parsing\n>> 2011.01 as January 2011, but it's a stretch from the existing formats:\n>>\n> \n> It would be far more logical to parse \"2011-01\" as \"January 2011\" as\n> that's the preferred way to write month-precision dates in most\n> countries that use both the metric system and the gregorian calender.\n> \n> I've never seen that date-type with dot as a separator, but with the\n> dash it's very, very common.\n\nSeconded. ISO dates are getting pretty common, and in the extended\nformat hyphens are the default separator between year, month, and date\n.\n\nA few notes on support:\n\nGNU `date` 8.5 parses some ISO date strings correctly:\n$ date --date='2001-02-03' +%Y-%m-%d\\ %H:%M:%S\n2001-02-03 00:00:00\n$ date --date='2001-02-03 04:05:06' +%Y-%m-%d\\ %H:%M:%S\n2001-02-03 04:05:06\n\nUnfortunately, it doesn't handle partial dates:\n$ date --date='2001-02' +%Y-%m-%d\\ %H:%M:%S\ndate: invalid date `2001-02'\n\nBut it does handle HH:MM:\n$ date --date='04:05' +%Y-%m-%d\\ %H:%M:%S\n2011-05-10 04:05:00\n\nBasic format dates are sometimes parsed correctly:\n$ date --date='20010203' +%Y-%m-%d\\ %H:%M:%S\n2001-02-03 00:00:00\n\nBut not with seconds:\n$ date --date='20010203040506' +%Y-%m-%d\\ %H:%M:%S\n2001020304-05-06 00:00:00\n\nThe W3C recommends the use of ISO dates:\n, and their standards, like XML,\ntypically support only ISO dates (or a subset thereof).\n\nCheers,\nVictor Engmark\n"},{"id":"167587","messageId":"4DC8F91C.5090709@drmicha.warpmail.net","threadId":"27308","inReplyTo":"4DC8EBD8.50707@terreactive.ch","subject":"Re: Approxidate with YYYY.MM","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-05-10T08:36:44Z","receivedAt":"2011-05-10T08:36:44Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Victor Engmark venit, vidit, dixit 10.05.2011 09:40:\n> On 05/10/2011 08:54 AM, Andreas Ericsson wrote:\n>> On 05/10/2011 08:35 AM, Michael J Gruber wrote:\n>>> Brian Gernhardt venit, vidit, dixit 09.05.2011 21:02:\n>>>> (This is in response to a discussion on #parrot.)\n>>>>\n>>>> Rakudo (https://github.com/rakudo/rakudo/) uses tags of the form\n>>>> YYYY.MM for their monthly releases. When we were attempting to find\n>>>> the cause of a slowdown, somewhat was trying to find what commits\n>>>> occurred after the 2011.01 release with \"git log --after=2011.01\".\n>>>> His mistake was pointed out but this led to the confusion of why this\n>>>> was parsed as \"May 1 2011\" instead of \"Jan 1 2011\". Shouldn't\n>>>> date.c:match_multi_number() parse something with only two numbers as\n>>>> a beginning of month instead of allowing it to pass through to the\n>>>> generic parsing?\n>>>\n>>> I just don't think there is a format like that. There is dd.mm.[yy]yy\n>>> and apparently also yyyy.mm.dd, but without leading zeros in mm for the\n>>> latter. Our date parser also takes \".\" for a space so that you don't\n>>> need to quote a space (\"1.day.ago\"). I can see the logic behind parsing\n>>> 2011.01 as January 2011, but it's a stretch from the existing formats:\n>>>\n>>\n>> It would be far more logical to parse \"2011-01\" as \"January 2011\" as\n>> that's the preferred way to write month-precision dates in most\n>> countries that use both the metric system and the gregorian calender.\n>>\n>> I've never seen that date-type with dot as a separator, but with the\n>> dash it's very, very common.\n> \n> Seconded. ISO dates are getting pretty common, and in the extended\n> format hyphens are the default separator between year, month, and date\n> .\n\nPlease, guys, this is not about ISO dates. It's about abbreviations of\nyyyy.mm.dd, and that is not ISO at all!\n\nIncidentally, we do not parse 2010-3 as March of 2010 either. Again,\nthis is not ISO date format (but an unofficial abbreviation). We may\ndecide to dwim that to 2010-03-01, and I would even appreciate that.\n\nBut yyyy.mm.dd is a format we don't support at all (because it's no\nstandard), so before supporting an abbreviation we would have to decide\nabout supporting that format.\n\n> A few notes on support:\n\n[notes about ISO dates cut]\n\nMichael\n"},{"id":"168448","messageId":"BANLkTik_kSx8cumFWxnoCze1T72yzBxkQQ@mail.gmail.com","threadId":"27308","inReplyTo":"4DC8F91C.5090709@drmicha.warpmail.net","subject":"Re: Approxidate with YYYY.MM","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-05-22T17:10:08Z","receivedAt":"2011-05-22T17:10:08Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Tue, May 10, 2011 at 08:36, Michael J Gruber\n wrote:\n> Incidentally, we do not parse 2010-3 as March of 2010 either. Again,\n> this is not ISO date format (but an unofficial abbreviation). We may\n> decide to dwim that to 2010-03-01, and I would even appreciate that.\n\nWouldn't it make the most sense to provide another option to allow the\nuser to specify whatever date format he wants (from the conversion\nspecifiers understood by strptime(3))?\n\nIt seems really ridiculous to keep growing the date parsing code.\n"}]}