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

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

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
>