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.santamaria@gmail.com> wrote:

On Sun, Mar 8, 2020 at 3:48 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

James Coleman <jtc331@gmail.com> writes:
> On Sat, Mar 7, 2020 at 9:31 PM Tom Lane <tgl@sss.pgh.pa.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.