From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73571 invoked by alias); 15 Nov 2016 01:38:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 73550 invoked by uid 89); 15 Nov 2016 01:38:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=jasan, Jasan, Rical, disadvantages X-HELO: aev204.rev.netart.pl Date: Tue, 15 Nov 2016 01:38:00 -0000 From: Rafal Luzynski Reply-To: Rafal Luzynski To: libc-alpha , Florian Weimer , Rical Jasan Message-ID: <1063625629.140370.1479173885642@poczta.nazwa.pl> In-Reply-To: <76b198b7-a35e-cbaf-ee15-339a196acab2@pacific.net> References: <1326125332.562051.1478737983449@poczta.nazwa.pl> <76b198b7-a35e-cbaf-ee15-339a196acab2@pacific.net> Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-Client: com.openexchange.ox.gui.dhtml X-SW-Source: 2016-11/txt/msg00487.txt.bz2 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. Regards, Rafal [1] http://austingroupbugs.net/view.php?id=258 [2] https://bugzilla.gnome.org/show_bug.cgi?id=749206