This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH v2 1/6] Implement alternative month names (bug 10871).


> 25.03.2016 02:54 Chris Leonard <cjlhomeaddress@gmail.com> wrote:
>
>
> Query:
>
> I'm not especially well versed in which languages have a nom/gen
> distinction, but I am aware of languages which have 13 months (because
> of lunar calendars). Is it safer to include an ALTMON_13 just in case
> of overlap between the two variants?

Sounds like a separate problem but my short answer is: it does not make
sense IMHO.

Indeed it's safer to add ALTMON_13 now than adding it later. But it won't
help you if you don't add MON_13 and ABMON_13. Adding such feature would
be even more horrible task than adding alternative (nominative/genitive)
month names. All nl_langinfo() constants are defined continuously, there
are no gaps between them. If you add MON_13 immediately after MON_12
you will increment the values of all constants after it and you will
break API. Also there are many places in glibc code which assume that
month numbers are 0..11 (12 values) and report an error if they are
outside this range. There is no way to configure the number of months
at the moment. You can add MON_13, ABMON_13 and ALTMON_13 at the end
of the LC_TIME category but then there are places which assume that
all month names make a continuous table and it's correct to refer to
them with a simple expression like month_name[tm_mon]. All those parts
would have to be rewritten.

Does glibc have any support for the lunar calendars? Looks like
it does not at all. Although probably it would be good idea for those
countries/locales which use such calendars.

Best regards,

Rafal


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]