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

po 24. 8. 2026 v 19:47 odesílatel Haibo Yan <tristan(dot)yim(at)gmail(dot)com> napsal:

> 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?
>

Current design is strict - same output, same input.

I can imagine a combination DD TMTAMMONTH - and this can be probably in
some situations wanted, but format parser doesn't allow combination of
prefixes. And if we accept alternative names when TM is used or localized
non alternative names when TAM is used, then it can be pretty messy. So
when TAM is used, then only alternative localized names can be accepted,
when TM, then only localized names can be accepted. Maybe in next versions
to_date will support soft errors and some combinations of formats, and this
can be ideal solution - like

to_date(val, 'DDTMMONTH', 'DDTMMONTH', 'DDMONTH', ...)

but this is another topic

Regards

Pavel

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
>