This is the mail archive of the
mailing list for the glibc project.
Re: Removing locale timezone information
- From: pinskia at gmail dot com
- To: "keld at keldix dot com" <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" <libc-locales at sourceware dot org>
- Date: Thu, 6 Aug 2015 20:01:17 +0200
- 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>
> 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:
>>> 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,
>>> 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.
> But it would be some effort to get all these data in place.
> If I should do it, I would write up a program using Olson data.
> This is not rocket science, and it seems that Olson data are compatible
> with LC_CTIME timezone capabilities.
> I think it has the merits of displaying times eg in "ls" correctly.
> Currently I think times displayed are incorrect for the times in Europe
> before the DST change for eg. most the September dates.
>>> Furthermore the locale spec facilitates a simpler initial setup avoiding
>>> one (or two) questions, and possibly automating the setup completely.
>>> This cannot be done just using POSIX spec in this area.
>> If everyone agrees we still want to do that despite the drawbacks listed
>> above and someone actually volunteers to all the work then we could
>> apply those patches once available in the future.
>> But while waiting for that to happen I propose we deal with the current
>> incorrect (as Paul pointed out) and inconsistent situation by removing
>> the data from those six locales I listed.
> I don't know. I would rather retain them and correct them. If I were
> to do some of this, I would like to add the info for some selected
> locales and try it out, and then also change localedef to address
> the new syntax for timing history, and then see how to have that
> implemented i "lS" and other places. Would that be feasible?
> Or would you need to have it all in one great patch?
> Obviously it does not work now.
> Best regards