https://bugs.winehq.org/show_bug.cgi?id=47866
Bug ID: 47866 Summary: comctl32:datetime: Fails in the Arabic locale Product: Wine Version: 4.17 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
The comctl32:datetime test fails in the Arabic locale:
datetime.c:212: Test failed: String mismatch ("12 hh" vs "hh 12") datetime.c:796: Test failed: Expected 01/10/2019, got 2019/10/01
https://test.winehq.org/data/tests/comctl32:datetime.html
This failure has been happening for a long time in the fg-win7u64-1spie9-ar VM but now the TestBot has a Windows 10 VM where the issue can be reproduced (w1064v1809_ar).
Since both VMs have different Windows versions and but fail in the same way in the same locale that seems to confirm that Arabic uses a different date format from what is expected.
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #1 from Henri Verbeet hverbeet@gmail.com --- (In reply to François Gouget from comment #0)
The comctl32:datetime test fails in the Arabic locale:
datetime.c:212: Test failed: String mismatch ("12 hh" vs "hh 12") datetime.c:796: Test failed: Expected 01/10/2019, got 2019/10/01
https://test.winehq.org/data/tests/comctl32:datetime.html
This failure has been happening for a long time in the fg-win7u64-1spie9-ar VM but now the TestBot has a Windows 10 VM where the issue can be reproduced (w1064v1809_ar).
Since both VMs have different Windows versions and but fail in the same way in the same locale that seems to confirm that Arabic uses a different date format from what is expected.
Probably not the issue here, but as an aside and perhaps despite perceptions, "Arabic" is not a locale any more than e.g. "English" or "French" are, and for things like date and time formats, the distinction between e.g. fr_CA, fr_CH and fr_FR actually matters.
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #2 from François Gouget fgouget@codeweavers.com --- Right. In this case it's ar_EG, Arabic:Egypt.
https://bugs.winehq.org/show_bug.cgi?id=47866
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=47866
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- As the errors show, DTM_SETFORMAT reverses the order of the tokens passed in. I did some experimenting and found that it only happens with v6. However, I couldn't easily figure out what's special about Arabic specifically. It's not just a matter of RTL script, because it doesn't happen with Hebrew. Maybe it's just hard-coded to Arabic in native comctl32?
I also am not familiar enough with date conventions to understand why date strings would be reversed in Arabic text (or Egyptian specifically) but not Hebrew.
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #4 from François Gouget fgouget@codeweavers.com --- Could it have nothing to do with RTL at all and just be different date/time conventions like in English (en_US) the date format is mm/jj/aaa but in French (at least fr_FR) it's jj/mm/aaaa? Note sure why it would be specific to v6 though. Maybe older versions did not always take the date/time convention into account?
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #5 from Zebediah Figura z.figura12@gmail.com --- (In reply to François Gouget from comment #4)
Could it have nothing to do with RTL at all and just be different date/time conventions like in English (en_US) the date format is mm/jj/aaa but in French (at least fr_FR) it's jj/mm/aaaa?
Except that it also happens with custom layouts (e.g. "12 hh" instead of "hh 12").
Note sure why it would be specific to v6 though. Maybe older versions did not always take the date/time convention into account?
Probably, yeah.
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #6 from Nikolay Sivov bunglehead@gmail.com --- Setting format is meant to override locale default. What's strange is that this changes actual window text. Normally any kind of reordering should only affect visual representation, not the storage.
Second test failing seems to be different, ar_EG date format should be DD/MM/YYYY as expected string shows, for some reason it's changed to YMD.
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #7 from Zebediah Figura z.figura12@gmail.com --- (In reply to Nikolay Sivov from comment #6)
Setting format is meant to override locale default. What's strange is that this changes actual window text. Normally any kind of reordering should only affect visual representation, not the storage.
Second test failing seems to be different, ar_EG date format should be DD/MM/YYYY as expected string shows, for some reason it's changed to YMD.
It looks like fundamentally the same failure, i.e. the tokens are reversed. In particular I'm imagining that the process of filling in numbers also includes reversing the tokens, not necessarily that the overridden format is stored in reverse. Is there something I'm misunderstanding?
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com --- I don't know. It's not clear to me what the purpose of this could be. Maybe it's some weird interaction with window RTL styles. I wonder what "'hh' ab" will return "ab 12" or "ba 12", and then "'hh'ab" with no space.
https://bugs.winehq.org/show_bug.cgi?id=47866
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- (In reply to Nikolay Sivov from comment #8)
I don't know. It's not clear to me what the purpose of this could be. Maybe it's some weird interaction with window RTL styles. I wonder what "'hh' ab" will return "ab 12" or "ba 12", and then "'hh'ab" with no space.
I did some testing, and:
* "'ab' hh" yields "12 ba"; * "ab hh" yields "12 ba" also; * "'ab'hh" yields "12ba"; " "حم hh" yields "12 مح" (so even RTL characters are reversed).
https://bugs.winehq.org/show_bug.cgi?id=47866
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major
--- Comment #10 from François Gouget fgouget@codeweavers.com --- The date changes with every run which means the date format issue is an "always new error". Because of this the TestBot will report most comctl32 patches as responsible for this failure(*) which should cause them to be rejected. Thus fixing this issue is high priority.
(*) Though at least in this case it won't if the last WineTest run happened on the same day. So don't submit comctl32 patches between midnight and 4am or on weekends I guess...
https://bugs.winehq.org/show_bug.cgi?id=47866
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED
--- Comment #11 from François Gouget fgouget@codeweavers.com --- These failures do not happen anymore but it is not clear why. Either some commit fixed the test, or Windows fixed this case some time between Windows 10 1809 and 2004 (see w10pro64_ar).
Either way I think this bug can be closed.
https://bugs.winehq.org/show_bug.cgi?id=47866
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.9.
-
WineHQ Bugzilla