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

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

>
> Best
> Bernd
>