Re: Solve a problem of LC_TIME of windows.

Magnus Hagander <magnus(at)hagander(dot)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.)

[For reviewers and testers]
For the above reason, please test the patch with some combinations
of locales and encodings, some of that might be different from
Windows' native ones.

[error result of strftime version]
$ initdb --locale=Japanese_Japan.20932 --encoding=eucjp

postgres=# SELECT name, setting FROM pg_settings WHERE name LIKE 'lc%';
name | setting
-------------+----------------------
lc_collate | Japanese_Japan.20932
lc_ctype | Japanese_Japan.20932
lc_messages | Japanese_Japan.20932
lc_monetary | Japanese_Japan.20932
lc_numeric | Japanese_Japan.20932
lc_time | Japanese_Japan.20932
(6 rows)

postgres=# SELECT to_char(now(), 'TMday');
ERROR: invalid byte sequence for encoding "UTF8": 0x00
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center