Re: Allow to_date() and to_timestamp() to accept localized names
От | Tom Lane |
---|---|
Тема | Re: Allow to_date() and to_timestamp() to accept localized names |
Дата | |
Msg-id | 27210.1580240270@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Allow to_date() and to_timestamp() to accept localized names (Mark Dilger <mark.dilger@enterprisedb.com>) |
Список | pgsql-hackers |
Mark Dilger <mark.dilger@enterprisedb.com> writes: >> On Jan 28, 2020, at 9:30 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> A brute-force answer, if there are few enough cases, is to recognize >> them regardless of the specific value of LC_TIME. Do we think >> anybody would notice or care if to_date('Sonnabend', 'TMDay') works >> even when in a non-German locale? > I think this only becomes a problem if there are weekday or month name collisions between languages where they have differentmeanings. As an absurd hypothetical, if “Sunday” in Tagalog means what “Tuesday” means in English, then you’vegot a problem. > This does happen for month abbreviations. “Mar” is short for “March” and variations in a number of languages, but shortfor “November” in Finnish. > For day abbreviations, “Su” collides between fi_FI and hr_HR, and “tor” collides between sl_SL and no_NO. But none of those cases are alternative names, so we wouldn't have entries for them in this hypothetical list. They'd only be recognized when strftime() returns them. I suspect also that the abbreviated names have few if any alternatives, so we may only need this whole hack for full names. A possible way of tightening things up without explicitly decoding the locale name is to make the entries of the list be string pairs: "if strftime() returned this, then also consider that". That puts a bit of a premium on knowing which names strftime considers primary, but I think we'd have had to know that anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: