Re: Solve a problem of LC_TIME of windows. - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Solve a problem of LC_TIME of windows.
Date
Msg-id 496522FA.6070805@tpf.co.jp
Whole thread Raw
In response to Re: Solve a problem of LC_TIME of windows.  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera wrote:
> ITAGAKI Takahiro wrote:
>> Hiroshi Inoue <inoue@tpf.co.jp> wrote:
>>
>>> Seems LC_CTYPE and LC_TIME should be convertible even though we use
>>> wcsftime (which internally calls strftime?).
>> Ok, wcsftime() requries both LC_TIME and LC_CTYPE are the same setting
>> (at least encoding) on Windows.
> 
> shouldn't this use LC_TIME?
> 
> +       setlocale(LC_CTYPE, locale_time);

AFAIK the results of strftime() is determined by LC_TIME and
LC_CTYPE. Date/time representations by LC_TIME language are
converted to LC_CTYPE codeset. In fact I can see the Chinese
strftome() representaions by Japanese codeset fortunately.

Our goal is to convert LC_CTIME representaions to the database
encoding. Though we expected that wcsftime() doesn't rely on
LC_CTYPE, wcsftime() relies on LC_CTYPE because it is almost =
strftime() + mbstowcs() and a problem occured e.g. when the
LC_CTYPE is set to "C".

regards,
Hiroshi Inoue




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Latest version of Hot Standby patch
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Adjust things so that the query_string of a cached plan and the