Message-ID: <496670C4.7090209@tpf.co.jp>
Date: Fri, 09 Jan 2009 06:31:48 +0900
From: Hiroshi Inoue <inoue@tpf.co.jp>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>,
	Magnus Hagander <magnus@hagander.net>
CC: Hiroshi Saito <z-saito@guitar.ocn.ne.jp>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Solve a problem of LC_TIME of windows.
References: <20090107140111.810A.52131E4D@oss.ntt.co.jp>
	<4964AD2D.7060009@hagander.net>
	<20090108113242.8B96.52131E4D@oss.ntt.co.jp>
In-Reply-To: <20090108113242.8B96.52131E4D@oss.ntt.co.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

ITAGAKI Takahiro wrote:
> Magnus Hagander <magnus@hagander.net> wrote:
> 
>> ITAGAKI Takahiro wrote:
>>> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
>>> (at least encoding) on Windows.
>>>
>> Hmm. Is this actually cleaner than using the original method as
>> suggested? Because if I understand things right, that version did *not*
>> require the setting of LC_CTYPE? (this is the version that uses strftime
>> and does two conversions)
> 
> No, we can't. I found strftime doesn't work if the database is
> initialized with non-C locale. It works only when lc_ctype = C and
> the encoding of lc_time is matched with Windows' one.
> On the other hand, wcsftime seems to be more robust.
> (The reason might come from mysterious msvcrt implementation.)

The setting of LC_CTYPE acts like a catalyst for wcsftime() to
work safely.

I checked the code around the patch and found the central function 
cache_locale_time() is rarely called (at most once per LC_TIME change).
The function cache_locale_time() calls strftime() only 38(=7*2+12*2)
  times. Now I fundamentally agree with Itagaki-san's patch. Though
it may not be the most effective code, it looks like the clearest one.

regards,
Hiroshi Inoue