On 4/23/2011 22:46, John Fremlin wrote:
Nikolay Sivovbunglehead@gmail.com writes:
On 4/23/2011 22:22, John Fremlin wrote:
Nikolay Sivovbunglehead@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@winehq.org when you think it's ready and you'll get some feedback if it's not.
-
Nikolay Sivov