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 >
