From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 5F4661F6A9 for ; Thu, 3 Jan 2019 00:21:44 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=tOf4Ymz46q1mENlP I6xRSVG0MJbumA3lVSCSiqGlpkPJklzwHIvjZj+K23tTK3IR1KsdWxr05RsdQnpJ gqhqXMzRZPP/0ckXg/FUPeZlSB6aZrjajQa2eq07A9Vz2HPSQPv1Q4Inuy6cpXt/ MYQGmeb2IvjZCOyqBqL1Ji8pFsc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type :content-transfer-encoding; s=default; bh=e0rNEvTm0ld4CufO6vRg1m TFkIk=; b=LZg20e3OpdpHg424vceJfe+10ZxkyvFzqd5YoOjlx6JVBEhcDzwOzr UG+MV/VtrUfxU5VtgdTs6uNlBKdRZ+cJDgzb3cnaKB74m9IH1BoaJyjK8G7/o+e7 Vc63v7lV8HHTXNZ7elYthBMF4kVykJMlyB4G7Vw4vlvT/iwTR+tto= Received: (qmail 20382 invoked by alias); 3 Jan 2019 00:21:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 19166 invoked by uid 89); 3 Jan 2019 00:21:41 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: shared-ano163.rev.nazwa.pl Date: Thu, 3 Jan 2019 01:20:45 +0100 (CET) From: Rafal Luzynski To: Siddhesh Poyarekar Cc: GLIBC Devel Message-ID: <2063591203.633198.1546474845289@poczta.nazwa.pl> In-Reply-To: <0c9a2e87-8b43-725a-d9cc-689ec032ba96@gotplt.org> References: <833db514-f25e-0c41-bf06-b8cc9272f1c2@gotplt.org> <87r2dv495n.fsf@oldenburg2.str.redhat.com> <1188732039.598484.1546429949188@poczta.nazwa.pl> <0c9a2e87-8b43-725a-d9cc-689ec032ba96@gotplt.org> Subject: Re: glibc 2.29 - Winter is coming... MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2.01.2019 19:24 Siddhesh Poyarekar wrote: >=20 > On 02/01/19 5:22 PM, Rafal Luzynski wrote: > > [...] > > [1] Cyrillic -> ASCII transliteration: I am not sure which locale shoul= d > [...] > However, I am acutely aware that I may not understand the gravity of=20 > some of the differences and you're free to throw my opinions out the=20 > window :) Thank you, I will reply in the proper thread. > > [2] [3] Default width for "%Ey" which is important due to the Japanese > > era change in 4 months. Also, this patch fixes handling of formatting > > flags so if that helps it can be split into the patches fixing the widt= h > > issue and fixing the flags issue. >=20 > A more detailed explanation of what the Japanese era change entails is=20 > needed in here, i.e. why is the padding needed Each Japanese era year is the year of reign of the current emperor. The current year is 31 (2 digits). As soon as the new era is announced, the new year will have the number 1 (one digit). As far as I understood, they do not want the year to be formatted as "1" but "01" instead because they want to keep the constant width output for example in logs. My reasoning is that "%y" is always zero-padded to 2 digits so for the consistency let's set "%Ey" to be zero-padded to 2 digits as well. The new Japanese era is already scheduled. [1] > and what would the output=20 > look like if we don't fix it in this release and why that would be a=20 > problem. For the comparison, here is the output of the current year and 1990 which had the same problem: $ LC_ALL=3Dja_JP.utf8 date +%Y 2019 $ LC_ALL=3Dja_JP.utf8 date +%EY =E5=B9=B3=E6=88=9031=E5=B9=B4 $ LC_ALL=3Dja_JP.utf8 date +%Y -d "29 years ago" 1990 $ LC_ALL=3Dja_JP.utf8 date +%EY -d "29 years ago" =E5=B9=B3=E6=88=902=E5=B9=B4 I think they want: "=E5=B9=B3=E6=88=9002=E5=B9=B4". An explanation why I use here "%Y" and "%EY" while we are talking about "%Ey". The reason is that "%EY" is expanded into a subformat which may contain "%Ey" as the actual year number. > Other than that, this seems like something we can make an exception for,= =20 > assuming that it does not affect translations. It does not affect translations of glibc but does affect translations of applications to a minor extent: the zero-padded output is one character wider than the non-zero-padded one. But: * this is exactly what they want, * the output for the current year (and 21 previous years) is already the same wide as a zero-padded single digit year. > I personally would have=20 > done 2 different patches, but I know others in the community who would=20 > have stuck this into a single patch so I don't have too strong an=20 > opinion about that aspect of this patch. The other issue is that the additional flags like "%-EY" or "%_EY" are ignored. I was going to say that this is not related with the era change but actually it is: as long as the year number had 2 digits those flags were correctly ignored. Now the users will have a good reason to expect them to work correctly. Regards, Rafal [1] https://en.wikipedia.org/wiki/2019_Japanese_imperial_transition