This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 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 <>
>>> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]