From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4053 invoked by alias); 5 Aug 2015 16:30:45 -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 127987 invoked by uid 89); 5 Aug 2015 16:20:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.3 required=5.0 tests=AWL,BAYES_50,BODY_8BITS,GARBLED_BODY,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: zimbra.cs.ucla.edu Message-ID: <55C237BE.1010806@cs.ucla.edu> Date: Wed, 05 Aug 2015 16:30:00 -0000 From: Paul Eggert User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: keld@keldix.com, Marko Myllynen , GNU C Library , libc-locales@sourceware.org Subject: Re: [PATCH] Remove locale timezone information References: <556F23C9.3030500@redhat.com> <557AE725.5050104@redhat.com> <20150805090748.GH26572@vapier> <20150805100126.GA11842@www5.open-std.org> <20150805102233.GA12350@www5.open-std.org> In-Reply-To: <20150805102233.GA12350@www5.open-std.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-q3/txt/msg00068.txt.bz2 On 08/05/2015 03:22 AM, keld@keldix.com wrote: > For countries with more timezones, the locale data helps narrowing down t= he > choices. And there are not that many countries with more than 1 timezone, > eg USA, Canada, Russia and Greenland. Many big countries like China and I= ndia > only have 1 timezone Actually, China has two time zones: tzdata's Asia/Shanghai and=20 Asia/Urumqi both reflect officially-kept time. Even Germany has more=20 than one tzdata entry, due to the a difference in post-1970 history of=20 timekeeping in its Swiss enclaves. So the problem of many time zones=20 for one locale is bigger than what you're suggesting, even if we ignore=20 traveling users (which is a pretty big class to ignore). As for tzdata names "not being culturally acceptable", they are intended=20 for use as internal identifiers, visible to experts like us but not to=20 end users, so "cultural acceptability" should not be an issue. End=20 users in China, for example, are not expected to see "Asia/Shanghai"=20 even in an English locale, but instead are expected to see "China=20 Standard Time" or "Beijing Time" or something like that. Strings like=20 "China Standard Time" and "=E5=8C=97=E4=BA=AC=E6=97=B6=E9=97=B4" are mainta= ined by the Unicode=20 Common Locale Data Repository and are widely=20 used in glibc-based systems. I don't know whether CLDR supports ISO TR=20 14652 and 30112, but if it doesn't then I suggest approaching the CLDR=20 maintainers.