Re: [PATCHES] Solve a problem of LC_TIME of windows.
От | ITAGAKI Takahiro |
---|---|
Тема | Re: [PATCHES] Solve a problem of LC_TIME of windows. |
Дата | |
Msg-id | 20081126114014.7D90.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [PATCHES] Solve a problem of LC_TIME of windows. ("Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>) |
Ответы |
Re: [PATCHES] Solve a problem of LC_TIME of windows.
|
Список | pgsql-hackers |
"Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> wrote: > Um, It was not supported. > http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ITAGAKI_PATCH.txt Hmm... the implementation of wcsftime() in msvcrt seems to be completely broken. I ran the attached test (localetest.c) and got the following results. The point is that wcsftime() returns the same character codes as strftime() i.e, the result is not an unicode string :-( The bug might be fixed in recently msvcrts in VC2005 or VC2008, but at least mingw uses the old broken C runtime. We'd better to use strftime() and multiple conversions to avoid the Microsoft's bug. ---- locale: C [Wednesday] C:str = 57 65 64 6e 65 73 64 61 79 C:wcs = 57 65 64 6e 65 73 64 61 79 locale: Japanese_Japan.932 SJIS:str = 90 85 97 6a 93 fa SJIS:wcs = 90 85 97 6a 93 fa locale: Japanese_Japan.20932 EUCJP:str = 90 85 97 6a 93 fa EUCJP:wcs = 90 85 97 6a 93 fa ---- NOTE: There is another problem that specified encoding is ignored by the functions. The result encoding is always platform default one. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: