Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: James Coleman <jtc331@gmail.com>
Cc: Juan José Santamaría Flecha <juanjo.santamaria@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Arthur Zakirov <zaartur@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-03-08T02:47:59Z
Lists: pgsql-hackers 
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.

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

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
$ env | grep ^LC_

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.

BTW, what platform are you using anyway?

			regards, tom lane

Commits

  1. Allow to_date/to_timestamp to recognize non-English month/day names.

  2. Clean up formatting.c's logic for matching constant strings.

  3. Implement standard datetime parsing mode

  4. Repair assorted issues in locale data extraction.