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 0C6B81F6A9 for ; Thu, 3 Jan 2019 14:32:23 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=oRsFX8wXf+W4UvMP ElXE5Y/gk0kt2a0IqYAMhCVq6mPFGnrrAo/pQydu+RNZN9AQXmmXeYEKTTUwd21j aNjDjj6WRAC47ZjZleNN859A0dowtPaHUj2xLj7W9Eir9BZ+iJIdi002C8pcfOxE PzqmKHnUs8ZYLWT6m+3xTn/Z43w= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=QJpDNtDx9X05G3YGHNhiH1 AEGTY=; b=dprD2pPGVoWArciVNUWEt0q/GnkIAWc3+62EZcacjccjYr5dt07DH4 124JR+UeioqyxhB3fwOTXPyyO9dODnsg9B3SyR23iMvo1620tu56BiWRKWpeSrvA t+iIb7LVZEdUWiKCiUbxxTVnwBFie/5rJYJTjcxKQuoHvDz1xz9EM= Received: (qmail 102417 invoked by alias); 3 Jan 2019 14:32:21 -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 102403 invoked by uid 89); 3 Jan 2019 14:32:20 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f182.google.com Subject: Re: glibc 2.29 - Winter is coming... To: Rafal Luzynski , Siddhesh Poyarekar Cc: GLIBC Devel 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> <2063591203.633198.1546474845289@poczta.nazwa.pl> From: Carlos O'Donell Openpgp: preference=signencrypt Message-ID: <75bc5d8f-d568-d5e1-aacf-fa19beaac81b@redhat.com> Date: Thu, 3 Jan 2019 09:32:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <2063591203.633198.1546474845289@poczta.nazwa.pl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 1/2/19 7:20 PM, Rafal Luzynski wrote: > 2.01.2019 19:24 Siddhesh Poyarekar wrote: >> Other than that, this seems like something we can make an exception for, >> 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 >> done 2 different patches, but I know others in the community who would >> have stuck this into a single patch so I don't have too strong an >> 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. I think that this should be split into two patches immediately. The "%-EY"/"%_EY" could go in as a bug fix right away. The default for padding needs more review but could be given an exception while we review the patch. I think both the patches should go in to 2.29, but need a little more work as Paul Eggert suggests. They are important changes to get into 2.29 because of the Japanese Era name change. Once the patches are in master they will allow the later patches in April to be applied once the Era name is announced. These changes are important to downstream enterprise distributions, but in that case we only care that they land in master at some point. We want a canonical solution that everyone is using. The new Era name will likely have to be backported to all the active open stable branches so they can display the new Era name. -- Cheers, Carlos.