This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Remove locale timezone information
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Keld Simonsen <keld at keldix dot com>
- Cc: Marko Myllynen <myllynen at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, <libc-locales at sourceware dot org>
- Date: Thu, 6 Aug 2015 20:15:37 +0000
- 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> <20150805155626 dot GA14334 at rap dot rap dot dk> <alpine dot DEB dot 2 dot 10 dot 1508051609310 dot 26234 at digraph dot polyomino dot org dot uk> <20150806180145 dot GE28963 at www5 dot open-std dot org>
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