Re: Removing locale timezone information

[pinskia at gmail dot com]

> On Aug 6, 2015, at 7:52 PM, keld@keldix.com wrote:
> 
>> On Fri, Jun 05, 2015 at 11:28:34AM +0300, Marko Myllynen wrote:
>> 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.
> 
> 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. 

Thanks,
Andrew


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