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

Ah, my bad. Meant to say Committer, of course :)

Bernd

Sent with Spark
On 23 Aug 2026 at 12:32 +0200, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, wrote:
>
>
> ne 23. 8. 2026 v 8:32 odesílatel Bernd Reiß <bd_reiss(at)gmx(dot)at> napsal:
> > Hi,
> >
> > On 23/08/2026 07:30, Pavel Stehule wrote:
> > > Hi
> > >
> > > pá 21. 8. 2026 v 18:56 odesílatel Bernd Reiß <bd_reiss(at)gmx(dot)at> napsal:
> > >
> > >     Hi Pavel,
> > >
> > >     On 8/18/26 8:47 PM, Pavel Stehule wrote:
> > >     > Hi
> > >     >
> > >     > so 15. 8. 2026 v 14:03 odesílatel Bernd Reiß <bd_reiss(at)gmx(dot)at
> > >     <mailto:bd_reiss(at)gmx(dot)at>> napsal:
> > >     >
> > >     >     Hi again,
> > >     >
> > >     >     thanks for the updated patch.
> > >     >     > 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.
> > >     >     The Locale standard actually mentions abbreviated
> > >     alternative month
> > >     >     names as
> > >     >     "ab_alt_mon" (see [1]). I tested this by setting your
> > >     TAMMONTH strftime
> > >     >     call to '%Ob'.
> > >     >     If we set the locale to Russian and call the function for
> > >     May this
> > >     >     actually returns
> > >     >     an abbreviated version of the month name:
> > >     >
> > >     >     Breakpoint 1, cache_locale_time () at pg_locale.c:772
> > >     >     772           if (strftime_l(bufptr, MAX_L10N_DATA, "%Ob",
> > >     timeinfo,
> > >     >     locale) <= 0)
> > >     >     (gdb) n
> > >     >     774                     bufptr += MAX_L10N_DATA;
> > >     >     (gdb) print bufptr
> > >     >     $4 = 0x7ffde4554630 "май"
> > >     >
> > >     >     Compared to the TMMON form of May in Russian this actually
> > >     makes a
> > >     >     difference:
> > >     >
> > >     >     postgres=# set lc_time='ru_RU.UTF8';
> > >     >     SET
> > >     >     postgres=# select to_char('2026-05-01'::date, 'TMMON');
> > >     >       to_char
> > >     >     ---------
> > >     >       МАЯ
> > >     >     (1 row)
> > >     >
> > >     >     postgres=# select to_char('2026-05-01'::date, 'TAMMONTH');
> > >     >       to_char
> > >     >     ---------
> > >     >       МАЙ
> > >     >     (1 row)
> > >     >
> > >     >     Again, TAMMONTH uses %Ob here. So I would argue for
> > >     implementing the
> > >     >     abbreviated
> > >     >     forms too.
> > >     >
> > >     >
> > >     > I implemented it - please check
> > >
> > >     LGTM. I compiled it and it works as expected. I also like the
> > >     introduction of
> > >     the get_localized_*_months functions. However, this leads to
> > >     suffix_len being
> > >     declared and set but never used in the DCH_MONTH, DCH_Month, and
> > >     DCH_month
> > >     cases (as well as for the abbreviated equivalents) in
> > >     DCH_from_char. Passing
> > >     NULL and guarding in the functions would be an option to avoid
> > >     this. However,
> > >     I don't feel strongly about this.
> > >
> > >     In DCH_to_char I think you forgot to refactor this if statement
> > >     for the
> > >     MON/Mon/mon cases?
> > >
> > >               if (strlen(str) <= (n->key->len + TM_SUFFIX_LEN) *
> > >     DCH_MAX_ITEM_SIZ)
> > >                 strcpy(s, str);
> > >
> > >
> > > this code is removed in new version
> > >
> > >
> > >     >
> > >     > Please check updated patch
> > >     >
> > >
> > >     With the if statements cleaned up this is a +1 for Ready for
> > >     Committer from me.
> > >
> > >
> > > Regards
> > >
> > > Pavel
> >
> > Patch applies cleanly now on HEAD. New changes LGTM. Compiles without
> > problems and
> > regression tests are all green. I am moving this to Ready for Reviewer.
>
> you are a reviewer :-)
>
> Pavel
> >
> > Best
> > Bernd