From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32450 invoked by alias); 3 Jun 2015 21:33:46 -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 12379 invoked by uid 89); 3 Jun 2015 20:34:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,RDNS_DYNAMIC,SPF_PASS autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: www.open-std.org Date: Wed, 03 Jun 2015 21:33:00 -0000 From: keld@keldix.com To: Marko Myllynen Cc: GNU C Library , libc-locales@sourceware.org Subject: Re: Removing locale timezone information Message-ID: <20150603203430.GC15814@www5.open-std.org> References: <556F23C9.3030500@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556F23C9.3030500@redhat.com> User-Agent: Mutt/1.4.2.2i X-SW-Source: 2015-q2/txt/msg00070.txt.bz2 On Wed, Jun 03, 2015 at 06:56:57PM +0300, Marko Myllynen wrote: > Hi, > > 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. You can chose to only use POSIX TZ and be wrong for a number of dates. or use the more elaborate spec and do a number of these dayes right. The fix deals with daylight savings specifications, which changed at some time in the USA amongst others. 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. Best regards keld