Re: [PATCH] Remove locale timezone information

[keld@keldix.com]

On Wed, Aug 05, 2015 at 06:53:11AM -0400, Mike Frysinger wrote:
> On 05 Aug 2015 12:22, keld@keldix.com wrote:
> > On Wed, Aug 05, 2015 at 12:01:26PM +0200, keld@keldix.com wrote:
> > > On Wed, Aug 05, 2015 at 05:07:48AM -0400, Mike Frysinger wrote:
> > > > On 12 Jun 2015 17:05, Marko Myllynen wrote:
> > > > > as discussed in the thread starting at
> > > > > 
> > > > > https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
> > > > > 
> > > > > it looks like the best options is to remove locale timezone information
> > > > > from locales which currently provide it (in incomplete or incorrect
> > > > > fashion) rather than to start duplicating tzdata info in glibc.
> > > > 
> > > > thanks, pushed now!
> > > 
> > > That is the wrong direction. Please revert the change.
> > 
> > Let me explain. We would like to make the installation process easier
> > for users. That is, if we can remove one more question under the installation
> > process of linux, that would be a  goal. If the timezone is fully determined
> > by the choice of locale, then there is no need to ask for the timezone.
> 
> having 6 out of 300+ locales define timezone info is not something people can 
> rely on.

Well, it takes time to build the info. Furthermore, if data is not available
they can always fall back to the TZ info. This is all spelled out in the standard.

> we also don't want to duplicate data that is *actively* maintained
> elsewhere (the tz lists). 

The relation between tz and country is not maintained anywhere else, except in some
distributions, AFAIK.

Anyway many of the data in locales are just duplication
of data maintained elsewhere. That is the main purpose of a locale, to collect
data that are often maintained elsewhere, in a big bundle so that a user
can easily select that big bundle for his/her environment.

> plus many locales span multiple timezones.

How many? I think it is not a majority (by far). 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!)

> i don't see crappy UIs as a problem glibc either can or should solve.  at the
> end of the day,

Ultimately glibc implements functionality that is benefitting the end user.
This data has one of its foremost usefulness in setting timezone info.

> trying to set the timezone based on the locale isn't going to
> cover everyone (even a significant number of people),

Most of the world would be covered.  A quick calculation: countries with more than
1 timezone: USA, Canada, Mexico, Greenland, Brazil, Russia, Australia.
In total about 800 mill people out of a world polulation of 7000 mill.
And for many of these countries, the choice is only between 2 or 3 zones,
ag: Brazil, Mexico, Greenland, Australia.
The only real problmatic countries are USA, Canada and Russia.

> especially as you move
> around.  i certainly don't want it being tied to my locale.  which means UIs
> are required to get this right.

Most people don't move. But if you travel, you can easily change timezone.
I regularily do that.

> if you want to bring timezone data into the locale fields, then it should be
> done consistently across the board and in a maintainable manner.  until that
> happens, having data in a measly 6 locales is more of a disservice imo.

It is a beginning, and instead of just removing it, I think we should rather
encourage this, and even set out to have an overall collection of the data.
Furthermore, the data does not harm, if it is correct.  It can be used as
explained in the standard, even if the data is only available for a few
countries, and there is a clear migration path specified.

Best regards
Keld