Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 61DD5632406 for ; Wed, 7 Jan 2009 17:48:09 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 22124-01 for ; Wed, 7 Jan 2009 17:47:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34]) by mail.postgresql.org (Postfix) with SMTP id DE079632416 for ; Wed, 7 Jan 2009 17:47:45 -0400 (AST) Received: (qmail 19692 invoked by uid 512); 7 Jan 2009 21:47:42 -0000 X-Authentication: inoue was authenticated by sd.tpf.co.jp at 7 Jan 2009 21:47:42 -0000 Received: from unknown (HELO ?192.168.11.3?) (219.61.40.6) by sd.tpf.co.jp with SMTP; 7 Jan 2009 21:47:42 -0000 Message-ID: <496522FA.6070805@tpf.co.jp> Date: Thu, 08 Jan 2009 06:47:38 +0900 From: Hiroshi Inoue User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alvaro Herrera CC: ITAGAKI Takahiro , Hiroshi Saito , pgsql-hackers Subject: Re: Solve a problem of LC_TIME of windows. References: <20081126174021.EFC6.52131E4D@oss.ntt.co.jp> <492D1707.3060403@tpf.co.jp> <20090107140111.810A.52131E4D@oss.ntt.co.jp> <20090107132252.GB14891@alvh.no-ip.org> In-Reply-To: <20090107132252.GB14891@alvh.no-ip.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.125 tagged_above=0 required=5 tests=DNS_FROM_RFC_BOGUSMX=2.125 X-Spam-Level: ** X-Archive-Number: 200901/507 X-Sequence-Number: 131151 Alvaro Herrera wrote: > ITAGAKI Takahiro wrote: >> Hiroshi Inoue 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