Re: Approxidate with YYYY.MM
- From
Michael J Gruber <git@drmicha.warpmail.net>
- Date
- May 10, 2011, 08:36 UTC
- Message-ID
- <4DC8F91C.5090709@drmicha.warpmail.net>
- In-Reply-To
- <4DC8EBD8.50707@terreactive.ch>
Victor Engmark venit, vidit, dixit 10.05.2011 09:40:
Show 32 quoted lines
> On 05/10/2011 08:54 AM, Andreas Ericsson wrote:
>> On 05/10/2011 08:35 AM, Michael J Gruber wrote:
>>> Brian Gernhardt venit, vidit, dixit 09.05.2011 21:02:
>>>> (This is in response to a discussion on #parrot.)
>>>>
>>>> Rakudo (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?
>>>
>>> I just don't think there is a format like that. There is dd.mm.[yy]yy
>>> and apparently also yyyy.mm.dd, but without leading zeros in mm for the
>>> latter. Our date parser also takes "." for a space so that you don't
>>> need to quote a space ("1.day.ago"). I can see the logic behind parsing
>>> 2011.01 as January 2011, but it's a stretch from the existing formats:
>>>
>>
>> It would be far more logical to parse "2011-01" as "January 2011" as
>> that's the preferred way to write month-precision dates in most
>> countries that use both the metric system and the gregorian calender.
>>
>> I've never seen that date-type with dot as a separator, but with the
>> dash it's very, very common.
>
> Seconded. ISO dates are getting pretty common, and in the extended
> format hyphens are the default separator between year, month, and date
> <https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Calendar_dates>.Please, guys, this is not about ISO dates. It's about abbreviations of yyyy.mm.dd, and that is not ISO at all!
Incidentally, we do not parse 2010-3 as March of 2010 either. Again, this is not ISO date format (but an unofficial abbreviation). We may decide to dwim that to 2010-03-01, and I would even appreciate that.
But yyyy.mm.dd is a format we don't support at all (because it's no standard), so before supporting an abbreviation we would have to decide about supporting that format.
> A few notes on support:
[notes about ISO dates cut]
Michael