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

On Wed, Aug 12, 2026 at 9:47 PM Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>
> Hi
>
> st 12. 8. 2026 v 23:51 odesílatel Bernd Reiß <bd_reiss(at)gmx(dot)at> napsal:
>>
>> Hi Pavel,
>>
>> I've looked into your patch and provide the review below.
>>
>> Threads I found touching TMMONTH + glibc:
>> https://www.postgresql.org/message-id/CALSKcLS3Zi4o0Ak5pNOheqmAiKWcez%2B%2BqwKvyPccvOz2v62QZQ%40mail.gmail.com
>> (Russian)
>> https://www.postgresql.org/message-id/14717914.JAiOoc7IO7%40utklippan
>>
>> I did not come across a prior thread proposing an implementation of what
>> this patch does. Worth noting that in the utklippan thread above, Tom Lane
>> suggested that a new format code or modifier would be the palatable way to
>> address a similar problem.
>>
>> Contents & Purpose
>> ==================
>> This patch gives users control over the case (genitive vs. nominative)
>> to use when pulling localized month names from glibc via the function
>> to_char(). The author proposes to add a TAMMONTH option for formatting
>> dates.
>>
>> Intended behaviour: TMMONTH uses the genitive form (if applicable to the
>> language; equivalent to %B) while TAMMONTH uses the nominative
>> (equivalent to %OB).
>>
>> The patch contains regression test cases. It also adds a corresponding
>> entry in the documentation.
>>
>> Initial Run
>> ===========
>> The patch applies cleanly to HEAD. The regression tests all pass
>> successfully against the new patch, but fail against pre-patched HEAD,
>> so the test cases are sane and do cover the new behavior.
>>
>> Manual Testing
>> ==============
>> The provided examples all work fine. However, I realized that the
>> shortened form TAMMON falls back to English instead of honouring
>> lc_time:
>>
>> postgres=# set lc_time to 'de_DE.UTF-8';
>> SET
>> postgres=# SELECT to_char(date '2026-03-01'::date, 'DD TMMON');
>> SELECT to_char(date '2026-03-01'::date, 'DD TAMMON');
>> to_char
>> ---------
>> 01 MÄR
>> (1 row)
>>
>> to_char
>> ---------
>> 01 MAR
>> (1 row)
>>
>> It looks like only the full-month cases (DCH_MONTH/Month/month) were
>> wired up for
>> TAM; the abbreviated cases (DCH_MON/Mon/mon) still test IS_SUFFIX_TM
>> only, so TAM
>> silently drops to the default English abbreviation. I'd expect TAMMON to
>> stay
>> localized.
>
>
> TAMMON is not implemented, because glibc doesn't provide an alternative form for abbreviated month names.
> It is a question if it is better to raise an error, return a non alternative name or just ignore this flag. I have not strong
> opinion about this. Inside DCH_to_char the prefix TM is ignored when it is not used. So I did the same.
>
> But I can imagine using localized abbreviation. It is possible for the Czech language - but I have not idea if it is true for other languages.
>
>>
>>
>> Code Review
>> ===========
>> I am not sure if this condition can be ever true:
>>
>> + if (IS_SUFFIX_TM(n->suffix) && IS_SUFFIX_TAM(n->suffix))
>>
>> In case this is not possible the subsequent error message will never be
>> thrown and the whole block is dead code.
>>
>> However, if there is a reason for this check, it would be nice to
>> have a comment mention it.
>
>
> Yes, I badly expected that prefixes could be mixed. I checked the code, and this is not possible, so I removed this check
>
>
>>
>>
>> One thing I am not entirely sure about is this line:
>>
>> + if (strftime_l(bufptr, MAX_L10N_DATA, "%OB", timeinfo, locale) <= 0)
>> + strftimefail = true;
>>
>> As far as I checked %OB is not supported on Windows:
>>
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/strftime-wcsftime-strftime-l-wcsftime-l?view=msvc-170
>>
>> I was, however, not able to confirm this on a Windows machine right now.
>> I might be able to do so on the weekend.
>>
>> However, the same problem exists with older glibc versions not supporting
>> %OB. As far as I understand strftime_l this will lead to it returning 0 and
>> therefore setting strftimefail to true always. Since this if statement
>> is evaluated
>> unconditionally I expect this to also influence the behaviour of TM.
>
>
> I am afraid about this case too, and I expect maybe some fallback mode there. But because
> I have not a Window machine or some machine with older glibc I decided to don't touch it
> for this moment.
>
> glibc older than 2.28 doesn't support %OB. On the second hand the result of %B is probably
> equal to expected result %B.
>
>>
>> Nitpicking & Conclusion
>> =======================
>> I feel like the documentation could explicitly mention the difference
>> between TMMONTH and TAMMONTH (i.e., mentioning genitive and nominative
>> like the Locale docs you mentioned do). I also think it would be
>> beneficial to
>> mention that this linguistic detail is specific to certain languages.
>
>
> please, if you can write this part of the doc. My English is not good enough to write well about these linguistic details.
> It is a problem primarily for slavic languages - like Czech or Russian - but maybe it can be a wide problem.
>
>>
>> Furthermore, in general I feel like the code could have more comments.
>> The single comment /* TAM suffix - localized alternative month name */
>> I would rather put outside the if-else block and set TAM directly in
>> relation
>> to TM there.
>>
>> All in all, this topic seems to have been a pain point for many people
>> as the discussion threads mentioned in the beginning attest. The patch
>> offers a solution to make glibc behaviour more predictable for users.
>> I see a very real use case here.
>
>
> Thank you very much for this immediate review
>
> Regards
>
> Pavel
>
>>
>> Best
>> Bernd
>>
>> On 12/08/2026 09:13, Pavel Stehule wrote:
>> > Hi
>> >
>> > út 11. 8. 2026 v 17:14 odesílatel Pavel Stehule
>> > <pavel(dot)stehule(at)gmail(dot)com> napsal:
>> >
>> >
>> >
>> > út 11. 8. 2026 v 17:06 odesílatel Pavel Stehule
>> > <pavel(dot)stehule(at)gmail(dot)com> napsal:
>> >
>> > Hi
>> >
>> > My customer reported an interesting issue. He needs translated
>> > month name, and then he use
>> > to_char(current_date, 'tmmonth');
>> >
>> > Unfortunately, glibc returns nouns in the genitive case
>> > instead of the nominative case.
>> >
>> > This is a glibc feature from the 2.28 release. Genitive case
>> > makes sense, when the result holds a day, but without it, it
>> > is messy.
>> >
>> > glibc has alternative month names, that can be taken by usage
>> > placeholder '%OB' of function strftime.
>> > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap07.html
>> > - see alt_mon.
>> >
>> > Can we enhance prefixes (maybe tmo) to be possible to use
>> > alternative names?
>> >
>> >
>> > example:
>> >
>> > pavel(at)nemesis:~/src/orafce$ date +'%B'
>> > srpna
>> > pavel(at)nemesis:~/src/orafce$ date +'%OB'
>> > srpen
>> > pavel(at)nemesis:~/src/orafce$ LANG=C date +'%OB'
>> > August
>> >
>> >
>> > attached patch that implements 'TAM' modifier for data/timestamp
>> > formatting
>> >
>> > Regards
>> >
>> > Pavel
>> >
>> >
>> > Regards
>> >
>> > Pavel
>> >
>> >
>> >
>> >
>> >
>>

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.

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