This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).
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