[2/2] shlwapi: Implement SHFormatDateTimeA/SHFormatDateTimeW with tests
bunglehead at gmail.com
Tue Mar 2 13:30:06 CST 2010
On 3/2/2010 21:13, Reece Dunn wrote:
> On 1 March 2010 17:39, Nikolay Sivov<bunglehead at gmail.com> wrote:
>> On 3/1/2010 20:01, Paul Vriens wrote:
>>> On 03/01/2010 12:56 AM, Nikolay Sivov wrote:
>>>> Implement SHFormatDateTimeA/SHFormatDateTimeW with tests.
>>>> Spotted in logs while testing IE6.
>>> Hi Nikolay,
>>> This one introduces failures on what appears Vista+ :
>>> Could you have a look?
>> Hi, Paul.
>> It looks like it adds some special characters on new versions. I'll take a
>> look. It could be LTR markers (I never saw them before though, only read
>> Also I suspect problems with formatting, but for now we could wait for
> Isn't it locale dependent? That is, you are passing
> LOCALE_USER_DEFAULT, so it will use the settings from the "Regional
> and Language Settings" on Windows (e.g. Japanese date format --
> "2010年3月2日", or user-specified).
Yes, it's dependent of course, that's why I'm calling GetDateFormat with
that locale specifier.
And I expect whatever defined in locale data, available with -A call as
well. For example I don't
think Japanese fails to get -A format even with specific characters
defined, that's what WideCharToMultiByte is for.
> Specifying an English LCID should work, but may fail if the user has
> entered a custom format containing special characters, so could still
> fail, It may also fail if English is not available.
I don't want to silence test failures actually, I'm going to run
additional test on failing boxes with testbot soon.
> Also, it might be useful to change the code page to a UTF-8 code page
> so that the SHFormatDateTimeA calls return UTF-8 strings and as a
> result, we can see what the characters are (if this is possible).
SHFormatDateTimeA doesn't return UTF-8 of course. I suspect special formatting characters.
> - Reece
More information about the wine-devel