Message-ID: <48DA044D.10005@hagander.net>
Date: Wed, 24 Sep 2008 11:11:41 +0200
From: Magnus Hagander <magnus@hagander.net>
User-Agent: Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Hiroshi Saito <z-saito@guitar.ocn.ne.jp>
CC: pgsql-patches@postgresql.org
Subject: Re: Solve a problem of LC_TIME of windows.
References: <03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D>
In-Reply-To: <03c301c91737$be5a2a30$0e01a8c0@IBMC9A0F63B40D>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hiroshi Saito wrote:
> Hi.
> 
> I have problem of LC_TIME of windows.(CVS-HEAD)
> 
> As for Version 8.3.3. It is edited by wrong gettext and is. (But, it is
> expressed.)
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png
> 
> 
> As for Version 8.4. It came to be used by Tom-san in strftime of
> Native-windowsAPI.
> It is good improvement.! But, strftime of Native returns a result by
> CODEPAGE of
> environment of operation by Windows with LC_TIME. In Japanese
> environment, return
> value is SJIS(CP932). Then, SJIS(CP932) can't be chosen by
> SERVER_ENCODING.:-(
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/pg84beta-03-to_char.png
> 
> Then, I'm proposal patch. It is solved splendidly.
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_EUCJP.txt
> 
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/DATECHECK_UTF8.txt

In principle, I think this patch looks good.

Do you (or somebody else) have an example where this breaks in an
encoding where I can actually understand the characters, though ;-) That
would make testing a whole lot easier...

Also, the patch needs error checking. strftime() can fail, and the
multibyte conversion functions can certainly fail. That will need to be
added.

//Magnus