From: Joseph Myers <joseph@codesourcery.com>
To: Keld Simonsen <keld@keldix.com>
Cc: Marko Myllynen <myllynen@redhat.com>,
GNU C Library <libc-alpha@sourceware.org>,
<libc-locales@sourceware.org>
Subject: Re: [PATCH] Remove locale timezone information
Date: Thu, 06 Aug 2015 21:46:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.10.1508061952390.30327@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20150806180145.GE28963@www5.open-std.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
next prev parent reply other threads:[~2015-08-06 21:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-03 15:57 Removing " Marko Myllynen
2015-06-03 21:33 ` Paul Eggert
2015-06-03 21:33 ` keld
2015-06-05 8:28 ` Marko Myllynen
2015-08-06 21:45 ` keld
2015-08-06 21:45 ` pinskia
2015-08-06 21:46 ` keld
2015-08-07 2:33 ` Rich Felker
2015-08-07 0:45 ` Mike Frysinger
2015-08-09 21:12 ` keld
2015-08-07 21:49 ` Paul Eggert
2015-08-09 21:12 ` keld
2015-08-09 21:12 ` Paul Eggert
[not found] ` <20150812140837.GA23436@www5.open-std.org>
2015-08-12 21:07 ` Paul Eggert
2015-08-12 21:07 ` Andreas Schwab
2015-08-12 21:07 ` Allan McRae
2015-08-12 21:07 ` Zack Weinberg
2015-08-12 23:13 ` Keld Simonsen
2015-08-12 23:13 ` Allan McRae
2015-06-12 14:05 ` [PATCH] Remove " Marko Myllynen
2015-08-05 9:07 ` Mike Frysinger
2015-08-05 11:51 ` keld
2015-08-05 11:51 ` keld
2015-08-05 10:53 ` Mike Frysinger
2015-08-05 11:52 ` keld
2015-08-05 12:39 ` Andreas Schwab
2015-08-05 13:09 ` keld
2015-08-05 13:33 ` Mike Frysinger
2015-08-05 15:56 ` Keld Simonsen
2015-08-05 16:30 ` Joseph Myers
2015-08-06 21:46 ` Keld Simonsen
2015-08-06 21:46 ` Andreas Schwab
2015-08-06 21:46 ` Zack Weinberg
2015-08-06 21:46 ` Joseph Myers [this message]
2015-08-06 2:53 ` Mike Frysinger
2015-08-05 11:52 ` Andreas Schwab
2015-08-05 11:52 ` keld
2015-08-05 12:30 ` Andreas Schwab
2015-08-05 13:03 ` keld
2015-08-05 16:30 ` Paul Eggert
2015-08-06 2:56 ` Mike Frysinger
2015-08-06 17:13 ` keld
2015-08-06 17:13 ` Paul Eggert
2015-08-06 17:22 ` keld
2015-08-06 17:14 ` pinskia
2015-08-06 17:25 ` keld
2015-08-06 17:14 ` keld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1508061952390.30327@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=keld@keldix.com \
--cc=libc-alpha@sourceware.org \
--cc=libc-locales@sourceware.org \
--cc=myllynen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).