VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales

[Nikolay Sivov]

On 4/23/2011 22:46, John Fremlin wrote:
> Nikolay Sivov<bunglehead at gmail.com>  writes:
>
>> On 4/23/2011 22:22, John Fremlin wrote:
>>> Nikolay Sivov<bunglehead at gmail.com>   writes:
>>>
>>>> On 4/23/2011 19:00, John Fremlin wrote:
>>>>> Europeans write dates generally as dd-mm-yyyy. This makes sense. So does
>>>>> yyyy-mm-dd. Native will parse dates written yyyy-mm-dd correctly. Wine for some
>>>>> reasons assumes they are yyyy-dd-mm. This is not a date ordering used anywhere
>>>>> as far as I know and contradicts the MS behaviour.
>>>>>
>>>>> I've submitted http://bugs.winehq.org/show_bug.cgi?id=26902
>>>>>
>>>>> I've included a patch which fixes the problem and adds a testcase. Is
>>>>> there anything I can do to improve the chances that this fairly
>>>>> unambiguous fix meets the next release? -- I have some secret and
>>>>> cunning plans which are unfortunately predicated on this being fixed.
>>>>> @@ -3458,6 +3458,7 @@ static void test_VarDateFromStr(void)
>>>>>       DFS("02.01.1970"); EXPECT_DBL(25570.0);
>>>>>       DFS("02.13.1970"); EXPECT_DBL(25612.0);
>>>>>       DFS("02-13-1970"); EXPECT_DBL(25612.0);
>>>>> +  DFS("2020-01-11"); EXPECT_DBL(43841.0);
>>>> Hi, John.
>>>>
>>>> This is locale-dependent thing, so it will need at least more tests
>>>> for different locales (locales with different default month/day order
>>>> I mean).
>>> Hi Nikolay,
>>>
>>> Is there really ever a locale which actually parses ydm under the native
>>> implementation?
>> Not really, as far as I know. My point was to test with different
>> pattern anyway. For example for
>> yyyy/mm/dd and dd/mm/yyyy locales. Also this particular test is not
>> very descriptive cause
>> month and day in it both fit month or day range, so you can't tell how
>> it's interpreted.
> I don't understand the confusion here?
>
> The single test extra test is explicitly for a date that can only be
> converted either as y-m-d or the imaginary Wine-only y-d-m format. That
> should be interpreted in exactly one way, and it is interpreted
> incorrectly at the moment. The patch fixes that.
Yes, I got it. Wine converts 2020-01-11 string as 1st of November while 
native treats it as 11th of January.
What I meant that test data should be clear about what field is day and 
what's a month.
For your case it could be '2020-01-30' to make 30 invalid value for a month.

> If you want extra tests, I'm sure they'd be great, but I think this
> pretty unambiguously represents an improvement.
About additional tests, what about cases like '2020-20-01' on locales 
that use 'mm/dd/yyyy' or
'2020-01-30' for locales that are 'dd/mm/yyyy'?

Even if you're sure patch doesn't break that it's always better to add 
more tests (maybe some tests for that are in already).
> Who has authority to approve it?
A patch? Alexandre Julliard, he's the only project maintainer. Send a 
patch to wine-patches at winehq.org when you think it's ready and you'll 
get some feedback if it's not.