From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79441 invoked by alias); 5 Jun 2015 08:28:42 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 79416 invoked by uid 89); 5 Jun 2015 08:28:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Message-ID: <55715DB2.2010500@redhat.com> Date: Fri, 05 Jun 2015 08:28:00 -0000 From: Marko Myllynen Reply-To: myllynen@redhat.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: keld@keldix.com CC: GNU C Library , libc-locales@sourceware.org Subject: Re: Removing locale timezone information References: <556F23C9.3030500@redhat.com> <20150603203430.GC15814@www5.open-std.org> In-Reply-To: <20150603203430.GC15814@www5.open-std.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-q2/txt/msg00072.txt.bz2 Hi, On 2015-06-03 23:34, keld@keldix.com wrote: > On Wed, Jun 03, 2015 at 06:56:57PM +0300, Marko Myllynen wrote: >> >> glibc allows defining timezone as part of locale information but very >> few locales do it, only 6 out of almost 300 locales implement it. The >> LC_TIME/timezone keyword is not in POSIX standards (but comes from ISO >> TR 14652) and the comment in programs/ld-time.c seems to suggest it was >> not such a good idea to begin with: >> >> /* XXX We don't perform any tests on the timezone value since this is >> simply useless, stupid $&$!@... */ >> >> I'm sure nobody wants to even think about duplicating tzdata information >> in glibc locale files so I propose that, in the name of consistency, we >> remove the existing timezone definitions from the shipped locale files >> but leave the actual code still available (to allow any possible custom >> locales defining it to be used). >> >> Thoughts? If there are no objections, I can file a BZ and submit a patch. >> >> The locales in question are: km_KH, lo_LA, my_MM, nan_TW@latin, th_TH, >> uk_UA. > > I suggest that we polulate the locales and also follow the extended syntax > of ISO TR 14652 and 30112. I don't think this would help anyone; applications are already using other means than glibc locales to deal with timezones, it would be quite an effort to populate those fields and in essence it would be just duplicating the data from tzdata in glibc locales for no obvious benefits. In addition, when timezones change, glibc maintainers would need to update the locale files, distribution maintainers would need to push out glibc updates, and system administrators would need to update also glibc, not just tzdata, to have the updated timezone data in place. > Furthermore the locale spec facilitates a simpler initial setup avoiding > one (or two) questions, and possibly automating the setup completely. > This cannot be done just using POSIX spec in this area. If everyone agrees we still want to do that despite the drawbacks listed above and someone actually volunteers to all the work then we could apply those patches once available in the future. But while waiting for that to happen I propose we deal with the current incorrect (as Paul pointed out) and inconsistent situation by removing the data from those six locales I listed. Thanks, -- Marko Myllynen