[PATCH] Remove locale timezone information

[Joseph Myers]

On Thu, 6 Aug 2015, Keld Simonsen wrote:

> On Wed, Aug 05, 2015 at 04:15:14PM +0000, Joseph Myers wrote:
> > On Wed, 5 Aug 2015, Keld Simonsen wrote:
> > 
> > > 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.
> > 
> > We should not duplicate the work done externally in tracking timezone 
> > changes, nor embed copies of such frequently changing data in glibc (the 
> > existing copies of timezone data are purely for use as test inputs for zic 
> > and time-related functions, not for installation).
> 
> I don't understand your attitude here. Most other data in locales are
> coming from somewhere else, such as the language codes, the country codes,
> the date formats, the character attributes, the collation sequence.

tzdata is updated many times a year, sometimes with no more than a few 
days' notice that a country is changing its timezone; I don't think 
countries change their collation rules with a few days' notice like that.  
GNU/Linux distributions have well-established processes for getting those 
updates out to users in a timely manner.  Note that tzdata comes from 
separate sources to glibc, and is built independently of glibc; anything 
built from the glibc source tree would be liable to require other binary 
packages built from the same source tree to be updated at the same time, 
which is not helpful.

A few years ago we deliberately stopped installing timezone data from 
glibc because it was much better for distributions to get the updates 
directly from the upstream project.  The principles haven't changed.

It's possible the tzdist protocol may become relevant in future for this 
purpose, or that glibc might gain support for rereading timezone data in 
future (relevant for long-running processes when timezone rules change).  
But I don't see timezone information in locales as being relevant to glibc 
in the future.  The path that leads to systems where timezone information 
in locales is relevant is a path that diverged from glibc (and Unix-like 
systems in general) a long time ago (over 20 years ago, at least, given 
how POSIX had separate interfaces for timezones and locales over 20 years 
ago and the tz database dates back to 1986 or before.

Timezones and locales are completely orthogonal in glibc.  Moving away 
from that would be a backwards step.  If anything, we should add 
interfaces involving explicit timezone objects (see bug 17651) just like 
the interfaces involving explicit locale objects to make it even more 
convenient for applications to use arbitrary combinations of locales and 
timezones when processing data where different records may involve 
different timezones.

-- 
Joseph S. Myers
joseph@codesourcery.com