[Bug 47866] New: comctl32:datetime: Fails in the Arabic locale
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(a)winehq.org Reporter: fgouget(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #1 from Henri Verbeet <hverbeet(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- Right. In this case it's ar_EG, Arabic:Egypt. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #3 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #4 from François Gouget <fgouget(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #5 from Zebediah Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #6 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #7 from Zebediah Figura <z.figura12(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #8 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 --- Comment #9 from Zebediah Figura <z.figura12(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major --- Comment #10 from François Gouget <fgouget(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from François Gouget <fgouget(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=47866 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.9. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla