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
