From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22909 invoked by alias); 10 Nov 2016 12:41:27 -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 22856 invoked by uid 89); 10 Nov 2016 12:41:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=novembre, authors, communities, situations X-HELO: mx1.redhat.com Subject: Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871). To: Rafal Luzynski 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> <579374375.2202122.1478605156225@poczta.nazwa.pl> <36cfa35f-bd1c-d880-ef85-185d07096c8d@redhat.com> <1326125332.562051.1478737983449@poczta.nazwa.pl> From: Florian Weimer Cc: libc-alpha@sourceware.org Message-ID: <9e1a0812-56fc-a002-a12c-59d7882cf19f@redhat.com> Date: Thu, 10 Nov 2016 12:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1326125332.562051.1478737983449@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00392.txt.bz2 On 11/10/2016 01:33 AM, Rafal Luzynski wrote: > I've discussed all possible solutions in [1], including what you > have proposed here. Shortly, no solution is perfect and each has > its advantages and disadvantages. Your solution has these pros: > > - does not cause any backward compatibility issues; > - does not break any existing application where the current solution > is correct. > > At the same time it has the following cons: > > - introduces incompatibilities with *BSD family (including OS X) and > with the probable future POSIX specification which will remain > forever - please read below why I find it important; Even the FreeBSD situation is in support of my proposal because implementing it would improve date formatting: [root@bsd ~]# uname -a FreeBSD bsd 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep 29 01:43:23 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 [root@bsd ~]# LC_ALL=ca_ES.UTF-8 date -j 201604141000 dijous, 14 de d’abril de 2016, 10:00:00 UTC [root@bsd ~]# LC_ALL=ca_ES.UTF-8 cal De novembre 2016 dg dl dt dc dj dv ds 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 In the date case, this is not even a third-party application using a hard-coded strftime argument, it's right in the base operating system, in the locale data. I couldn't test Thunderbird because it did not pick up the Catalan language pack for some reason, but the sources use "de %B" as a date format, so I expect that they are broken on FreeBSD, too. I think this shows that whatever is currently proposed for POSIX has plenty of unintended consequences. > - does not actually solve the problem for any existing application > until the authors or translators change %B to %OB (in case of open > source programs we can reach the upstreams and suggest solution). Yes, but this has to be weighed against all the applications which are broken after the change. > My solution has these pros: > > - will automagically solve the problems for all applications where > it is broken; Not true, see the FreeBSD example, where the full-format date string is still incorrect. > - will remain compatible with an existing *BSD solution and possible > future POSIX specification. FreeBSD has to fix things anyway, so changing the approach would not create additional work for them. > Also has this disadvantage: > > - will break some existing applications where current solution is correct; Some? Most exiting applications (which use date formats) for some locales, I would say. > but: > > - in case of open source software we can reach the upstreams and suggest > solution; > - in case of closed source software distributed in a binary form we can > provide a backward compatible ABI which will provide the old behaviour > for older programs. I think we should, if at all possible, avoid situations were mere recompilation of an application introduces subtle changes. Software is increasingly bundled and compiled by downstream developers and not distributions. > I believe there are less cases where the a month name is displayed > standalone than those where it is displayed with a day number therefore > I believe that a fallout caused by applications broken by my solution > is smaller than the fallout caused by the applications broken now. This might be true for affected Slavic locales (but I haven't investigated). > And the severity of the new bugs is equal to the severity of the current > bugs. I think for Romance languages with elision, the slightly incorrect “de” is preferred to the “de de” or “de d'” we'd get with your approach (and as the FreeBSD example shows, these situations are hardly temporary, but the bugs stick around for quite some time). >> I am worried that this puts pressure on us *not* to >> introduce mangled month names at all for these languages. > > Local language communities will have a chance to decide whether > they want this change or not. Same as with German, no change will > be visible until the locale data are updated. Each language will have > to provide their data, or, if all locale data will be copied from CLDR, > they will be able to revert the change. They do not have much choice here if they do not want to break most applications temporarily. Florian