From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59759 invoked by alias); 8 Nov 2016 11:39:29 -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 59682 invoked by uid 89); 8 Nov 2016 11:39:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*x:Mailer, H*UA:Mailer, polish, greek X-HELO: aev204.rev.netart.pl Date: Tue, 08 Nov 2016 11:39:00 -0000 From: Rafal Luzynski Reply-To: Rafal Luzynski To: libc-alpha@sourceware.org, Florian Weimer Message-ID: <579374375.2202122.1478605156225@poczta.nazwa.pl> In-Reply-To: <238ab162-7ff7-d90e-9f95-630ac413a064@redhat.com> References: <758885038.1799972.1477615768169@poczta.nazwa.pl> <71b7640e-55b0-06a5-1dff-b0fcbaf0eea9@redhat.com> <1458120697.2205845.1478343189427@poczta.nazwa.pl> <238ab162-7ff7-d90e-9f95-630ac413a064@redhat.com> 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: quoted-printable X-Originating-Client: com.openexchange.ox.gui.dhtml X-SW-Source: 2016-11/txt/msg00268.txt.bz2 Hi, TL;DR: German language is probably not affected by this bug so will not be affected by the change. You will not see any difference. If you thought otherwise that's only because of my lack of precision and I'm sorry for this. More details below: 7.11.2016 15:13 Florian Weimer wrote: > > > On 11/05/2016 11:53 AM, Rafal Luzynski wrote: > > 4.11.2016 14:40 Florian Weimer wrote: > >> > >> > >> On 10/28/2016 02:49 AM, Rafal Luzynski wrote: > >>> As %OB format specifier has been added to strftime/wcsftime > >>> family of functions backward compatibility implementation must be > >>> provided for older binaries which assume that %B returns > >>> a month name in the nominative case. > >> > >> I think this is a misuse of symbol versioning. Why would I want to pick > >> up this change when compiling from source, but not for existing binari= es? > >> > >> Florian > > > > There may be applications which rely on the fact that "%B" > > returns the month name in a nominative case. An example is cal(1) > > which has been pointed out in [1]. Their source code should be > > changed to use "%OB" but it cannot be expected from the existing > > binaries. > > > You could also ask how to provide the backward compatibility > > for the applications compiled from source. > > Yes, that's what I'm concerned about. > > > I think it's impossible and it's been kinda agreed in [2]. > > I think we should strive to provide backwards compatibility for > applications and not alter the meaning of %B, and rather change %c to > use %OB (or whatever the source of the month name in genitive ends up to > be) instead of %B. I was considering this approach and I've abandoned it because the only reason why I was considering it was because I had misread the POSIX proposal. More details: https://sourceware.org/bugzilla/show_bug.cgi?id=3D10871#c39 While at this, changing %c and also %x would be required but insufficient because applications often use their custom formats like day-month or weekday-day-month which are neither %c nor %x. > One example where this matters is German. It's good that you mention a specific language. My knowledge of German is next to zero but fortunately I have someone to ask for more details. > If POSIX requires that %B > returns the genitive case, as has been suggested, It seems to me that here is the root of misunderstanding and if it's caused by my lack of precision then I apologize for this. I have always used the terms "genitive case" and "nominative case" only as shortcuts because I should actually say "month name in a form appropriate when formatting a full date including a day number" and "month name in a form appropriate when formatting a month name standalone, without a day number". Occasionally I also refer to this full expression. There are languages which require genitive when formatting with date and nominative when standalone; there may be other languages which require another pair of forms (although I'm not aware of any such language), and there are languages which require always one form (nominative) although they also have genitive form which is not applicable here, an example is German probably. CLDR refers to "stand-alone" and "format", it seemed to ambiguous to me. More info: http://cldr.unicode.org/translation/date-time#TOC-Stand-Alone-vs.-Format-St= yles Now when I look at http://austingroupbugs.net/view.php?id=3D258 I can see they made the same error: they emphasize genitive and nominative case while they should emphasize "with a day number" and "no day number" and put "genitive" and "nominative" in parentheses only as possible examples of how some languages implement this feature. > then all applications > which currently use %B are broken Are they broken already? When you type this command: $ date +"%d %B %Y" is it broken in German locale? In Polish it's broken, so is in Czech, Russian, also in Finnish, Greek, and more. If it's also broken in German then you'll be happy to see the change. If it's not broken then you don't need any change. > because I have yet to see a > mechanically generated German date string which actually needs the > genitive case. In current usage, they only occur in phrases such =E2=80= =9Con > the last Sunday of November=E2=80=9D. Note that a genitive form will be used only if it is provided in locale data. So if German language has a genitive form but does not require (or even prohibits) using it when formatting a full date then all you have to do is not to provide any changes to the locale, just leave it as is. My patch provides a way to provide two different forms for month names but this second form is optional. There will be no change visible if there are no changes in the locale data. That's the reason why I have also provided sample locale data for some languages; these changes are not intended to be committed (although may be committed if translators apparently find them correct). In your example, a phrase =E2=80=9Con the last Sunday of November=E2=80=9D = looks like an attempt to employ strftime() to generate natural language sentences rather than to format a date. It's been discussed in bugzilla and stated that strftime() will never be suitable for this. > Does this clarify my position? > > Thanks, > Florian I think so and also now I'd like to ask: does this answers your questions? Thank you for your participation and support, I'll appreciate more feedback from you and from other people. Regards, Rafal