[Bug 54149] New: shlwapi:ordinal - test_SHFormatDateTimeA() fails on the mixed locales configuration
https://bugs.winehq.org/show_bug.cgi?id=54149 Bug ID: 54149 Summary: shlwapi:ordinal - test_SHFormatDateTimeA() fails on the mixed locales configuration Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: shlwapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- test_SHFormatDateTimeA() fails on the mixed locales configuration: ordinal.c:1765: Test failed: expected (mercredi 14 décembre 2022), got (mercredi 14 decembre 2022) ordinal.c:1773: Test failed: expected (mercredi 14 décembre 2022), got (mercredi 14 decembre 2022) ordinal.c:1787: Test failed: expected (mercredi 14 décembre 2022) got (mercredi 14 decembre 2022) for date part ordinal.c:1801: Test failed: expected (mercredi 14 décembre 2022) got (mercredi 14 decembre 2022) for date part See https://test.winehq.org/data/patterns.html#shlwapi:ordinal All was fine until 2022-12-09. Then on the 11th I let the TestBot rebuild the snapshot [1] to ensure that Internet time synchronization would be disabled to fix random failures in other tests. And on the 12th this test started failing: the date lost its e-acute! Yet the WineTest system information shows that none of the locale settings changed, not even the code page. Before and after they are: SystemDefaultLCID 0411 UserDefaultLCID 040c ThreadLocale 0411 SystemPreferredUILanguages 0412,0409 UserDefaultUILanguage 0412 ThreadUILanguage 0412 Country 231 ACP 932 The test did not change and the binary from the 9th has the same failure. So it is some obscure Windows setting that changed for some unknown reason. Furthermore given that the code page is 932 I would expect the plain 'e' to be the more correct result. Unfortunately there is no record of what the result was before the test started failing. Is it possible for SHFormatDateTimeA() and GetDateFormatA() to use different code pages? [1] It goes like this: that VM has a 'langs' powered-off snapshot with all the locales installed. This snapshot has not changed since 2022-04-24. From this the TestBot produces the 'langs-mx-MX-live' live snapshot using LibvirtTool.pl and SetWinLocale to change the locale settings. -- 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=54149 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs(a)winehq.org |fgouget(a)codeweavers.com OS|Linux |Windows 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=54149 --- Comment #1 from François Gouget <fgouget(a)codeweavers.com> --- Note: It is now clear that the test fails whenever the month contains accentuated letters: * December / décembre -> fails * January / janvier -> no accent, succeeds * February / février -> fails That means there are only 3 months in the year where this test fails: December, February and August. * August / août -> fails -- 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=54149 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- The failure happens because in the mixed locales test configuration the result and expected strings have different encodings. The tested API, SHFormatDateTimeA(), uses the 932 Shift-JIS code page which corresponds to CP_ACP and CP_THREAD_ACP. This causes it to use a regular 'e' in 'février'. But the expected string is built by GetDateFormatA() which uses the 1252 Latin I code page and thus contains an e acute. I did not find a way to have GetDateFormatA() use the code page we need: I tried all the LOCALE_XXX constants, GetUserDefaultLCID() and GetThreadLocale(). But in fact that attempt was doomed from the start: for GetDateFormatA() the language and the encoding are tied so the only cases where it produces the French string we need are when it uses the 1252 French code page. This is different from SHFormatDateTimeA() which produces a French string, as per the configured format locale, but using the current thread's encoding, which in this mixed locale configuration is derived from the MUI Korean locale. The fix is to use GetDateFormatW() and do the ANSI conversion ourselves. -- 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=54149 --- Comment #3 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to François Gouget from comment #2)
I did not find a way to have GetDateFormatA() use the code page we need: I tried all the LOCALE_XXX constants, GetUserDefaultLCID() and GetThreadLocale(). But in fact that attempt was doomed from the start: for GetDateFormatA() the language and the encoding are tied so the only cases where it produces the French string we need are when it uses the 1252 French code page.
Wine supports LOCALE_USE_CP_ACP here. I haven't verified that Windows does as well, but according to MSDN it should. -- 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=54149 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |a662f00e6bdaec3c403be6997fd | |48fefbd7774ad --- Comment #4 from François Gouget <fgouget(a)codeweavers.com> --- This got fixed by the commit below: commit a662f00e6bdaec3c403be6997fd48fefbd7774ad Author: François Gouget <fgouget(a)codeweavers.com> AuthorDate: Thu Mar 2 16:00:46 2023 +0100 shlwapi/tests: Fix the date formatting tests when the locale does not match the code page. In particular, February dates contain an e-acute in French, the representation of which depends on the code page being used, which in SHFormatDateTimeA() is CP_ACP. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54149 Also the test was patched so the failing case does not just happen in February, August and December: commit 90dfa808bfddb8a7fd6ec19a2ce13953ea4a2aa0 Author: François Gouget <fgouget(a)codeweavers.com> AuthorDate: Thu Mar 2 16:03:28 2023 +0100 shlwapi/tests: Make sure to test the formatting of troublesome dates. Test the current date to ensure broad coverage, and specifically test a February date because, in the French locale, it shows that SHFormatDateTimeA() uses the CP_ACP code page, not the locale's default one. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54149 -- 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=54149 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.3. -- 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