This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Removing locale timezone information

> On Aug 6, 2015, at 7:52 PM, wrote:
>> On Fri, Jun 05, 2015 at 11:28:34AM +0300, Marko Myllynen wrote:
>> Hi,
>>> On 2015-06-03 23:34, 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. 


> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]