From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82727 invoked by alias); 6 Aug 2015 21:45:58 -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 25131 invoked by uid 89); 6 Aug 2015 17:52:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 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: Thu, 06 Aug 2015 21:45: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: <20150806175226.GD28963@www5.open-std.org> References: <556F23C9.3030500@redhat.com> <20150603203430.GC15814@www5.open-std.org> <55715DB2.2010500@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55715DB2.2010500@redhat.com> User-Agent: Mutt/1.4.2.2i X-SW-Source: 2015-q3/txt/msg00078.txt.bz2 On Fri, Jun 05, 2015 at 11:28:34AM +0300, Marko Myllynen wrote: > 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. Well, we always need to update glibc with the current stuff, that is normal glibc maintenance. We always need to change locales if the backgrund data changes. For instance if Greece gets a new currency, we need to change that in our locales. I thing tz data changes are not very frequent, but I may be wrong. It has not changed for most of the European countries for many years. But it would be some effort to get all these data in place. If I should do it, I would write up a program using Olson data. This is not rocket science, and it seems that Olson data are compatible with LC_CTIME timezone capabilities. I think it has the merits of displaying times eg in "ls" correctly. Currently I think times displayed are incorrect for the times in Europe before the DST change for eg. most the September dates. > > 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. I don't know. I would rather retain them and correct them. If I were to do some of this, I would like to add the info for some selected locales and try it out, and then also change localedef to address the new syntax for timing history, and then see how to have that implemented i "lS" and other places. Would that be feasible? Or would you need to have it all in one great patch? Obviously it does not work now. Best regards keld