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.  (Hiroshi Inoue <inoue@tpf.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Re: Simple postgresql.conf wizard -- Statistics idea...
Следующее
От: "Robert Haas"
Дата:
Сообщение: Re: Column reordering in pg_dump