This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Remove locale timezone information
- From: Keld Simonsen <keld at keldix dot com>
- To: Marko Myllynen <myllynen at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, libc-locales at sourceware dot org
- Date: Wed, 5 Aug 2015 17:56:26 +0200
- Subject: Re: [PATCH] Remove locale timezone information
- Authentication-results: sourceware.org; auth=none
- References: <556F23C9 dot 3030500 at redhat dot com> <557AE725 dot 5050104 at redhat dot com> <20150805090748 dot GH26572 at vapier> <20150805100126 dot GA11842 at www5 dot open-std dot org> <20150805102233 dot GA12350 at www5 dot open-std dot org> <20150805105311 dot GK26572 at vapier> <20150805113049 dot GB16488 at www5 dot open-std dot org> <20150805133305 dot GM26572 at vapier>
On Wed, Aug 05, 2015 at 09:33:05AM -0400, Mike Frysinger wrote:
> On 05 Aug 2015 13:30, firstname.lastname@example.org wrote:
> > On Wed, Aug 05, 2015 at 06:53:11AM -0400, Mike Frysinger wrote:
> > > having 6 out of 300+ locales define timezone info is not something people can
> > > rely on.
> > Well, it takes time to build the info.
> how much time exactly do you think is reasonable ? it's been more than 10 years
> and clearly no one thus far cares enough to drive this. if you do, then feel
> free, but until that happens i see no reason to restore the incomplete data.
Yes, it has taken quite a long time. Maybe because the locales that people build on
do not have timezone info, and maybe because 14652 timezone syntax was not supported by
glibc, including DST history changes.
I don't know. I think I could add timezone info since the epoch based on
the Olson data for each of the locales. Would you be positive about committing such changes
Mike? I would then have to write up a program for that.
Do we use Olson tz data in any of the glibc functions?
> > How many? I think it is not a majority (by far).
> seeing as how people literally travel around the world now, and mobility is only
> increasing, any combo is fair game now.
Why is changing the timezone in an app not a satisfactory way of handling this?
You must acknowledge that the multiple timezone per country is a quite limited problem,
only really valid for the USA, Canada and Russia. I don't know where you are from,
but could you consider that it would be an improvement for the vast majority of the
world, even if it was not as great for you?
Anyway using geoip could solve part of this, as you note below.
But when you travel, you normally would like to retain most of your environment
such as the language, only TZ info would need to change.
> > Anyway, as I explained,
> > even if there are more timezone choices for a locale, then it is an improvement
> > to have the choices instead of a cumbersome clicking on a map, which selects
> > Washington DC or New York as a default (sic!)
> which is why there's been a rise to use packages like geoip to automatically
> detect an appropriate region based on the network connectivity, gps, cellular
> stations, or other sources.
Yes, that is a good way forward but for initial setup of a machine, one still
would need the coupling on the geoip data with a locale, and then the coupling
of a locale to a timezone. So still the timezone info coupled to the locale
is very useful.
> i've just snipped the rest because none of the responses i found convincing
> and rehashing things is going nowhere. sorry.
Well, also sorry that we don't agree on the purpose of glibc, and on making the life of
end users easier, and making time display correct. It also seems like we have different
ways of counting the people in the world, or at least giving importance to them.