This is the mail archive of the
mailing list for the glibc project.
Re: Removing locale timezone information
- From: Rich Felker <dalias at libc dot org>
- To: pinskia at gmail dot com
- Cc: "keld at keldix dot com" <keld at keldix dot com>, Marko Myllynen <myllynen at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, "libc-locales at sourceware dot org" <libc-locales at sourceware dot org>
- Date: Thu, 6 Aug 2015 22:30:49 -0400
- Subject: Re: Removing locale timezone information
- Authentication-results: sourceware.org; auth=none
- References: <556F23C9 dot 3030500 at redhat dot com> <20150603203430 dot GC15814 at www5 dot open-std dot org> <55715DB2 dot 2010500 at redhat dot com> <20150806175226 dot GD28963 at www5 dot open-std dot org> <EE629769-A7DF-42C3-B58D-C1F373D0F010 at gmail dot com>
On Thu, Aug 06, 2015 at 08:01:17PM +0200, email@example.com wrote:
> > On Aug 6, 2015, at 7:52 PM, firstname.lastname@example.org wrote:
> >> On Fri, Jun 05, 2015 at 11:28:34AM +0300, Marko Myllynen wrote:
> >> Hi,
> >>> On 2015-06-03 23:34, email@example.com wrote:
> >>>> On Wed, Jun 03, 2015 at 06:56:57PM +0300, Marko Myllynen wrote:
> >>>> glibc allows defining timezone as part of locale information but very
> >>>> few locales do it, only 6 out of almost 300 locales implement it. The
> >>>> LC_TIME/timezone keyword is not in POSIX standards (but comes from ISO
> >>>> TR 14652) and the comment in programs/ld-time.c seems to suggest it was
> >>>> not such a good idea to begin with:
> >>>> /* XXX We don't perform any tests on the timezone value since this is
> >>>> simply useless, stupid $&$!@... */
> >>>> I'm sure nobody wants to even think about duplicating tzdata information
> >>>> in glibc locale files so I propose that, in the name of consistency, we
> >>>> remove the existing timezone definitions from the shipped locale files
> >>>> but leave the actual code still available (to allow any possible custom
> >>>> locales defining it to be used).
> >>>> Thoughts? If there are no objections, I can file a BZ and submit a patch.
> >>>> The locales in question are: km_KH, lo_LA, my_MM, nan_TW@latin, th_TH,
> >>>> uk_UA.
> >>> I suggest that we polulate the locales and also follow the extended syntax
> >>> of ISO TR 14652 and 30112.
> >> I don't think this would help anyone; applications are already using
> >> other means than glibc locales to deal with timezones, it would be quite
> >> an effort to populate those fields and in essence it would be just
> >> duplicating the data from tzdata in glibc locales for no obvious
> >> benefits. In addition, when timezones change, glibc maintainers would
> >> need to update the locale files, distribution maintainers would need to
> >> push out glibc updates, and system administrators would need to update
> >> also glibc, not just tzdata, to have the updated timezone data in place.
> > Well, we always need to update glibc with the current stuff, that is normal
> > glibc maintenance.
> > We always need to change locales if the backgrund data changes.
> > For instance if Greece gets a new currency, we need to change that in our
> > locales. I thing tz data changes are not very frequent, but I may be wrong..
> > It has not changed for most of the European countries for many years.
> U.S. Timezones has changed in the last ten years due to a few
> different things. One is an addition of a leap second. Another was
> to daylight savings time (summer time) start/end date. And then
> there was Indiana Timezone changes due to deciding to have daylight
> savings time.
Leap seconds are not a timezone change. The offset between UTC and the
local timezone does not change. Only the offset between UTC and TAI
changes, and this has nothing to do with time zones.