Re: Removing locale timezone information

[Paul Eggert <eggert@cs.ucla.edu>]

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.