Mark Dilger <mark.dil...@enterprisedb.com> writes:
> But then the manual page goes on to say:
>> %E* %O*
>> POSIX locale extensions. The sequences %Ec %EC %Ex %EX %Ey %EY %Od %Oe %OH
>> %OI %Om %OM %OS %Ou %OU %OV %Ow %OW %Oy are supposed to provide alternate
>> representations.
>>
>> Additionally %OB implemented to represent alternative months names (used
>> standalone, without day mentioned).
> This is the part I haven’t played with, but it sounds like it can handle at
> least one alternate name. Perhaps you can get the alternates this way?
This sounded promising, but the POSIX strftime spec doesn't mention %OB,
so I'm afraid we can't count on it to do much. At this point I'm not
really convinced that there are no languages with more than two forms,
anyway :-(.
I also wondered whether we could get any further by using strptime() to
convert localized month and day names on-the-fly, rather than the patch's
current approach of re-using strftime() results. If strptime() fails
to support alternative names, it's their bug not ours. Unfortunately,
glibc has got said bug (AFAICS anyway), so in practice this would only
offer us plausible deniability and not much of any real functionality.
In the end it seems like we could only handle alternative names by
keeping our own lists of them. There are probably few enough cases
that that wouldn't be a tremendous maintenance problem, but what
I'm not quite seeing is how we'd decide which list to use when.
Right now, locale identifiers are pretty much opaque to us ... do
we really want to get into the business of recognizing that such a
name refers to German, or Greek?
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?
regards, tom lane
