VarDateFromStr parses yyyy-mm-dd as yyyy-dd-mm in European locales
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.
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).
Nikolay Sivov <bunglehead(a)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? The patch is clearly an improvement I think . . . I could restrict it solely to apply to the English UK locale if that would satisfy the concern? It would meet my needs. I've tested it under English UK for all dates up to 100k (which crashed gcc amusingly until compiled without optimization).
On 4/23/2011 22:22, John Fremlin wrote:
Nikolay Sivov<bunglehead(a)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.
participants (2)
-
John Fremlin -
Nikolay Sivov