Re: [PATCH] Remove locale timezone information

[Keld Simonsen <keld at keldix dot com>]

On Wed, Aug 05, 2015 at 09:33:05AM -0400, Mike Frysinger wrote:
> On 05 Aug 2015 13:30, keld@keldix.com 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.

Best regards
Keld