Re: missing possibility to use alternative translated month names in to_char function

On Sat, Aug 22, 2026 at 10:36 AM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> Hi
>
>>
>> >>
>>
>> The use case makes sense to me, but I wonder a bit about the abstraction
>> boundary here.
>>
>> TA exposes a fairly specific locale/grammatical distinction as part of the
>> to_char() format language. Is this something we want to make part of the
>> long-term SQL-facing API, rather than leaving context-sensitive localization
>> to the application/localization layer?
>>
>> I’m not objecting to the patch, but if other locale-specific grammatical forms
>> come up later, would we expect to keep adding similar modifiers? Maybe this
>> particular distinction is common enough to justify it, but I think the i
>> intended boundary is worth considering.
>
>
> The design is based on glibc locales - and they introduced just one alternative form - no others.
>
> I don't have a knowledge about other languages than Czech language, but generally there are used only two forms for name of month
>
> 1. in combination with day - 2024-07-01 ... 1 července 2024 - this is always combination day, month
> 2. Just the name of the month .. červenec - this form can be combined with day, but can be used as an isolated name of month (in this case, only this form).
>
> Sometimes can be used third form (little bit obsolete) ... k 1 červenci (this form is not supported by any library)
>
> The form @2 was the historical default of all libraries that support localized month names. glibc 2.28 z 2018 changed form to @1, and original values were moved to alternative names.
>
> libicu has a similar design (with different names) - it supports two forms of month name - MMMM (month in year) and LLLL (stand-alone month in year). No other form is supported.
>
> https://unicode-org.github.io/icu/userguide/format_parse/datetime/#formatting-dates
>

Thanks for the explanation. The comparison with ICU’s contextual vs.
stand-alone forms makes the scope much clearer to me.

Looking through the patch, one thing I was wondering about is the to_date()
side. The original problem is about choosing the representation produced by
to_char(), but TAM is also made part of the input parsing semantics.

For example, DD TAMMONTH YYYY searches the alternative localized month names,
while DD TMMONTH YYYY searches the regular localized names. Is TAM intended to
specify the grammatical form accepted on input as well, or is this distinction
primarily an output-formatting choice?

I don’t have a strong opinion either way, but it seems worth defining
explicitly since this becomes part of the format model too.

> Regards
>
> Pavel
>
>>
>>
>> I’m not a committer, so I may be missing some of the context here, and I’m
>> happy to defer to others who have more experience with this area.
>>
>> Regards,
>> Haibo