public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Rafal Luzynski <digitalfreak@lingonborough.com>
To: libc-alpha <libc-alpha@sourceware.org>,
	 Florian Weimer <fweimer@redhat.com>,
	 Rical Jasan <ricaljasan@pacific.net>
Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).
Date: Tue, 15 Nov 2016 01:38:00 -0000	[thread overview]
Message-ID: <1063625629.140370.1479173885642@poczta.nazwa.pl> (raw)
In-Reply-To: <76b198b7-a35e-cbaf-ee15-339a196acab2@pacific.net>

11.11.2016 04:52 Rical Jasan <ricaljasan@pacific.net> 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.

Regards,

Rafal

[1] http://austingroupbugs.net/view.php?id=258
[2] https://bugzilla.gnome.org/show_bug.cgi?id=749206

  reply	other threads:[~2016-11-15  1:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-28  0:49 Rafal Luzynski
2016-11-04 13:40 ` Florian Weimer
2016-11-05 10:53   ` Rafal Luzynski
2016-11-07 14:13     ` Florian Weimer
2016-11-08 11:39       ` Rafal Luzynski
2016-11-09 10:49         ` Florian Weimer
2016-11-10  0:33           ` Rafal Luzynski
2016-11-10 12:41             ` Florian Weimer
2016-11-10 18:42               ` Rafal Luzynski
2016-11-10 19:19                 ` Andreas Schwab
2016-11-15  1:21                   ` Rafal Luzynski
2016-11-11  3:52             ` Rical Jasan
2016-11-15  1:38               ` Rafal Luzynski [this message]
2016-11-15 11:09                 ` Rafal Luzynski
2016-11-16 13:06                 ` Rical Jasan
2016-11-17 11:18                   ` Rafal Luzynski
2016-11-18  9:22                     ` Rical Jasan
2016-11-22 23:56                       ` Rafal Luzynski
2016-11-09 11:00       ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1063625629.140370.1479173885642@poczta.nazwa.pl \
    --to=digitalfreak@lingonborough.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=ricaljasan@pacific.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).