This is the mail archive of the 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 v4 06/11] Provide backward compatibility for strftime family (bug 10871).

11.11.2016 04:52 Rical Jasan <> wrote:
> On 11/09/2016 04:33 PM, Rafal Luzynski wrote:
> > Is there any committee in glibc which would decide which way to choose?
> I'm not aware of any actual committees other than consensus on the list,
> so I'd like to cast my vote here. Locales are not an area of speciality
> for me and I've only just kept an eye on this thread, so hopefully I'm
> understanding this correctly, but on a high level, changing the meaning
> of a format specifier already in use raises a red flag, compared to the
> alternative of introducing a new one, with new meaning or behaviour.
> Introducing a new one avoids "breaking" the code other people have
> written -- right, wrong, or indifferent -- and makes "fixing" one's code
> a voluntary action, if the new behaviour is actually what's desired.
> That seems more appropriate to me.
> Rical

Thank you, Rical for your feedback.  It's valuable even if I don't
agree.  I'm sorry if I'm repeating the same thing again but as you
said that locales are not an area of speciality for you I'd like to
summarize again what are the disadvantages if we decide to implement
genitive (full date) format as ALTMON_x and %OB and leave nominative
(standalone) format unchanged as MON_x and %B:

- glibc and *BSD family will remain incompatible forever;
- also glibc will remain forever incompatible with the possible
  future change in POSIX [1];
- we will have trouble to define what should be the specification
  of g_date_strftime() and g_date_time_printf() providing that Glib
  is a multiplatform library [2];
- no application will be fixed until it switches to the new features:
  ALTMON_x and %OB; this means all applications which display dates
  except those which display months names standalone (e.g., calendars).

Maybe it should be somehow counted how many applications use
nl_langinfo/strftime/wcsftime to display month names standalone
and how many in full date context?

Technically, both implementation are not much different.  Nothing
inside the pipeline says whether MON_x/%B are genitive or
nominative, except the code which provides the backward compatible
behaviour.  Otherwise it's only a matter of convention: we provide
nominative (or genitive) month names in their appropriate places
in locale data and say the users that they can retrieve them
using MON_x, ALTMON_x, %B, and %OB.  I'm advocating my solution
not because it has any technical advantages (actually, it is
more difficult to implement) but because I think it's good
to ensure compatibility with existing standards.  Note that *BSD
family introduced its change in the end of 1990s.  Maybe it's
good to read what were their reasons behind choosing that way
of implementation.




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