Re: Removing locale timezone information

[keld at keldix dot com]

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.

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