This is the mail archive of the
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 <firstname.lastname@example.org> 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:1912//07//30:1912//12//31:<U5927><U6B63>:%EC<U5143><U5E74>";/
>>>> + "+:1:1912//07//30:1912//12//31:<U5927><U6B63>:%EC<U5143><U5E74>";/
>>> OK with the remarks mentioned above.
>>> Reviewed-by: Rafal Luzynski <email@example.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