Re: Removing locale timezone information

[Marko Myllynen <myllynen at redhat dot com>]

Hi,

On 2015-06-03 23:34, keld@keldix.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.

> 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.

Thanks,

-- 
Marko Myllynen