On Sat, Mar 7, 2020 at 9:48 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > James Coleman <jtc...@gmail.com> writes: > > On Sat, Mar 7, 2020 at 9:31 PM Tom Lane <t...@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. > > Do you get different results from "date" depending on the locale? > I get > > $ LANG=C date > Sat Mar 7 21:44:24 EST 2020 > $ LANG=tr_TR.utf8 date > Cts Mar 7 21:44:26 EST 2020 >
$ LANG=C date Sun Mar 8 09:27:50 EDT 2020 $ LANG=tr_TR.utf8 date Paz Mar 8 09:27:54 EDT 2020 $ LANG=tr_TR date Sun Mar 8 09:27:57 EDT 2020 I'm curious if you get something different for that last one (no utf8 qualifier). on my Fedora 30 box. > > Another possibility perhaps is that you have partial locale settings > in your environment that are bollixing the test. Try > > $ env | grep ^LANG > This gives me: LANG=en_US.UTF-8 LANGUAGE=en_US > $ env | grep ^LC_ > Nothing for this. > If there's more than one relevant environment setting, and they > don't all agree, I'm not sure what would happen with our > regression tests. > There's LANG and LANGUAGE but they look like they effectively agree to me? > BTW, what platform are you using anyway? > ElementaryOS 5.1 Hera, which is built on top of Ubuntu 18.04.3 LTS (and Linux 4.15.0-72-generic). This suggests I have the standard Ubuntu Turkish language packages installed: $ dpkg -l | grep language-pack-tr ii language-pack-tr 1:18.04+20180712 all translation updates for language Turkish ii language-pack-tr-base 1:18.04+20180712 all translations for language Turkish James