From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-74673-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 95016 invoked by alias); 11 Nov 2016 03:52:29 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 94980 invoked by uid 89); 11 Nov 2016 03:52:27 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=committees, Hx-languages-length:892, family
X-HELO: mail.pacific.net
Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime
 family (bug 10871).
To: Rafal Luzynski <digitalfreak@lingonborough.com>,
        libc-alpha <libc-alpha@sourceware.org>,
        Florian Weimer <fweimer@redhat.com>
References: <1326125332.562051.1478737983449@poczta.nazwa.pl>
From: Rical Jasan <ricaljasan@pacific.net>
Message-ID: <76b198b7-a35e-cbaf-ee15-339a196acab2@pacific.net>
Date: Fri, 11 Nov 2016 03:52:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <1326125332.562051.1478737983449@poczta.nazwa.pl>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Null-Tag: 7f51d22ca73488c98ba1c587a0c5f5ac
X-SW-Source: 2016-11/txt/msg00426.txt.bz2

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