Mark Dilger <mark.dil...@enterprisedb.com> writes:
>> On Jan 28, 2020, at 9:30 AM, Tom Lane <t...@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 different meanings. As an
> absurd hypothetical, if “Sunday” in Tagalog means what “Tuesday” means in
> English, then you’ve got a problem.
> This does happen for month abbreviations. “Mar” is short for “March” and
> variations in a number of languages, but short for “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
