Re: Allow to_date() and to_timestamp() to accept localized names

On Sun, Mar 8, 2020 at 7:17 AM Juan José Santamaría Flecha <
juanjo(dot)santamaria(at)gmail(dot)com> wrote:

>
>
> On Sun, Mar 8, 2020 at 3:48 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> James Coleman <jtc331(at)gmail(dot)com> writes:
>> > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> >> Looks like you may not have Turkish locale installed? Try
>> >> locale -a | grep tr_TR
>>
>> > Hmm, when I grep the locales I see `tr_TR.utf8` in the output. I assume
>> the
>> > utf8 version is acceptable? Or is there a non-utf8 variant?
>>
>> Hmm ... I'm far from an expert on the packaging of locale data, but
>> the simplest explanation I can think of is that the tr_TR locale exists
>> to some extent on your machine but the LC_TIME component of that is
>> missing.
>>
>
> AFAICS, the locale 'tr_TR' uses the encoding ISO-8859-9 (LATIN5), is not
> the same as 'tr_TR.utf8'.
>

The test name implies it's about utf8, though, which makes me wonder if the
test should be testing utf8 instead?

That being said, a bit more googling based on your node about the proper
ISO encoding turned up this page: https://unix.stackexchange.com/a/446762

And I confirmed that the locale you mentioned is available:
$ grep "tr_TR" /usr/share/i18n/SUPPORTED
tr_TR.UTF-8 UTF-8
tr_TR ISO-8859-9

So I tried:
echo tr_TR.ISO-8859-9 >> /var/lib/locales/supported.d/local # In a root
session
sudo dpkg-reconfigure locales

That didn't seem to fix it, though `locale -a` still only lists tr_TR.utf8,
so I'm still at a loss, and also unclear why a test names utf8 is actually
relying on an ISO encoding.

James