This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] ja_JP locale: Fix the offset in era-string for Taisho gan-nen [BZ #24162]
On 2/20/19 5:29 PM, Rafal Luzynski wrote:
> 20.02.2019 08:54 Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> On 2/18/19 6:27 PM, Rafal Luzynski wrote:
>>>> diff --git a/localedata/locales/ja_JP b/localedata/locales/ja_JP
>>>> index 1fd2fee..9bfbb2b 100644
>>>> --- a/localedata/locales/ja_JP
>>>> +++ b/localedata/locales/ja_JP
>>>> @@ -14951,7 +14951,7 @@ era
>>>> "+:2:1990//01//01:+*:<U5E73><U6210>:%EC%Ey<U5E74>";/
>>>> "+:2:1927//01//01:1989//01//07:<U662D><U548C>:%EC%Ey<U5E74>";/
>>>> "+:1:1926//12//25:1926//12//31:<U662D><U548C>:%EC<U5143><U5E74>";/
>>>> "+:2:1913//01//01:1926//12//24:<U5927><U6B63>:%EC%Ey<U5E74>";/
>>>> - "+:2:1912//07//30:1912//12//31:<U5927><U6B63>:%EC<U5143><U5E74>";/
>>>> + "+:1:1912//07//30:1912//12//31:<U5927><U6B63>:%EC<U5143><U5E74>";/
>>>> "+:6:1873//01//01:1912//07//29:<U660E><U6CBB>:%EC%Ey<U5E74>";/
>>>> "+:1:0001//01//01:1872//12//31:<U897F><U66A6>:%EC%Ey<U5E74>";/
>>>> "+:1:-0001//12//31:-*:<U7D00><U5143><U524D>:%EC%Ey<U5E74>"
>>>
>>> OK with the remarks mentioned above.
>>>
>>> Reviewed-by: Rafal Luzynski <digitalfreak@lingonborough.com>
>>>
>>> Also I think that the issue is important and this patch does not depend
>>> on other patches so it is also OK to backport it to old stable branches.
>>> However, I'd like to hear an opinion of other maintainers about it.
>>
>> This is hard to judge. Sometimes backporting date changes like this can
>> cause sorted dates to change their order, and that's not expected in a
>> stable release. I would be cautious and not backport this.
>
> If I understand correctly, a new Japanese era began on 1912-07-30 and
> from that day til the end of the year the year number should be 1.
> Currently that year number is 2 in glibc which is incorrect. Also whole
> year 1913 has the same number 2 in glibc which is correct. This already
> breaks sorting. I think that backporting this may only help and will
> not break anything.
>
> Do you sustain your objection against backporting? If not, do you have
> any suggestion how many stable versions should be fixed?
My objection is not sustained. I only wanted to point out that in a stable
release customers expect sortings to be stable and correctness is not always
an important factor. This is what I have seen in my experience working on
RHEL as an enterprise distribution. A bug is something you can document, but
once a list order changes it can have a chain of consequences that are harder
to fix. So for enterprise: change is the enemy.
This is upstream glibc, and so we can argue that the value of the fix is higher
than the value of a stable sorting. So I can support backporting the fix to
a stable branch if required, but unless someone is asking for it, I would not
backport it.
--
Cheers,
Carlos.