On Wed, Aug 12, 2026 at 9:47 PM Pavel Stehule <[email protected]> wrote: > > Hi > > st 12. 8. 2026 v 23:51 odesílatel Bernd Reiß <[email protected]> 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 >> > <[email protected]> napsal: >> > >> > >> > >> > út 11. 8. 2026 v 17:06 odesílatel Pavel Stehule >> > <[email protected]> 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@nemesis:~/src/orafce$ date +'%B' >> > srpna >> > pavel@nemesis:~/src/orafce$ date +'%OB' >> > srpen >> > pavel@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
