Re: Removing locale timezone information

[Rich Felker <dalias at libc dot org>]

On Thu, Aug 06, 2015 at 08:01:17PM +0200, pinskia@gmail.com wrote:
> 
> 
> > 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.

Leap seconds are not a timezone change. The offset between UTC and the
local timezone does not change. Only the offset between UTC and TAI
changes, and this has nothing to do with time zones.

Rich