This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
Re: Removing locale timezone information
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: keld at keldix dot com
- Cc: Marko Myllynen <myllynen at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, libc-locales at sourceware dot org
- Date: Wed, 12 Aug 2015 08:31:17 -0700
- Subject: Re: Removing locale timezone information
- Authentication-results: sourceware.org; auth=none
- References: <556F23C9 dot 3030500 at redhat dot com> <20150603203430 dot GC15814 at www5 dot open-std dot org> <55715DB2 dot 2010500 at redhat dot com> <20150806175226 dot GD28963 at www5 dot open-std dot org> <55C51D35 dot 8060406 at cs dot ucla dot edu> <20150809145027 dot GA5048 at www5 dot open-std dot org> <55C7773F dot 30205 at cs dot ucla dot edu> <20150812140837 dot GA23436 at www5 dot open-std dot org>
keld@keldix.com wrote:
My impression is that timezone changes are normally announced in due time
so that they can be included in normal glibc release schedule, which
I think is about twice a year, but irregulary.
No, that's incorrect. We sometimes get only a few days' notice. For tomorrow's
change in North Korea, we got one week's notice. We released a new tz version
Monday. We average about ten releases a year.
If there were an easy way tzselect could ask glibc "What country am I in?"
from a shell script
Oh well, specs to do it has been available for something like 2 decades in 14652.
How can a time-oriented shell script use 14652 to ask "What country am I in?",
preferably getting a 2-letter code? I don't see anything in 14652's description
of LC_TIME that would help an application discover what country the
application's clocks should be set to.
Also, in 14652 LC_TIME's timezone keyword doesn't provide for TZ settings like
'America/Los_Angeles' or 'Europe/Berlin' that are quite common in practice and
are more useful than POSIX TZ settings. So it doesn't appear that the
14652-standardized info would be of much use to tzselect.
I would much rather have users pick the
locale, and then present them with some defaults, that then can be changed
if necessary. And if geoip is available, then present a default
and likely selection of locales based on that.
Certainly geolocation helps, but how would this be put into a glibc-style
locale? 14652 doesn't provide for geolocation. Most modern apps support TZ
selection by maintaining their own geographical databases. If it's really the
intent to move this info into the locale, it sounds like a big project.
Once one has geolocation, the older selection mechanisms seem clumsy and
outdated and really, not worth spending much time on. So not only were the
recently-removed timezone entries in glibc locales unused and woefully
incomplete, application writers typically don't want that particular info anyway.
If (despite all my discouragment :-) you still want to improve locale timezone
support for old-fashioned non-geolocation applications, I like Zack Weinberg's
suggestion. From tzselect's point of view, it'd be mildly helpful if a shell
script could get a list of plausible TZ settings for the current locale, along
with an informal description of each setting so that non-expert users could make
an informed choice. tzselect is already doing this now with its own database,
but if glibc locales provided that information instead I suppose tzselect could
use it.