https://bugs.winehq.org/show_bug.cgi?id=54149
--- Comment #2 from François Gouget fgouget@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.