Re: [RFC][PATCH v4 06/11] Provide backward compatibility for strftime family (bug 10871).

[Florian Weimer <fweimer@redhat.com>]

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