This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Removing locale timezone information 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]