Removing locale timezone information

Removing locale timezone information

[Marko Myllynen]

Hi,

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.

Thanks,

-- 
Marko Myllynen

Re: Removing locale timezone information

[keld]

On Wed, Jun 03, 2015 at 06:56:57PM +0300, Marko Myllynen wrote:
> Hi,
> 
> 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. You can chose to only use POSIX TZ and be wrong
for a number of dates. or use the more elaborate spec and do a number
of these dayes right. The fix deals with daylight savings specifications,
which changed at some time in the USA amongst others. 

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.

Best regards
keld

Re: Removing locale timezone information

[Marko Myllynen]

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

Re: Removing locale timezone information

[keld]

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

Re: Removing locale timezone information

[pinskia]

> 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

Re: Removing locale timezone information

[keld]

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

I think the level of changes in Europe are the same, only a few in a decade.
This can easily be managed by current glibc mantenence schedule, and  distributin
maintenance schedule. Actually if Olson tz data is maintained in a distribution,
it would follow a similar schedule.

Anyway, are Olson tzdata used in GNU interfaces?

Best regards
Keld

Re: Removing locale timezone information

[Rich Felker]

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

Re: Removing locale timezone information

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On 06 Aug 2015 19:52, keld@keldix.com wrote:
> 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.

across the world, there are usually multiple changes every year.  sometimes
with very short notice (weeks or even days).  simply read the history of the
tzdata package if you want data.  distros updating the timezone database and
porting it back to older releases is trivial.  patching & pushing glibc
updates are not.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Removing locale timezone information

[keld]

On Thu, Aug 06, 2015 at 08:45:24PM -0400, Mike Frysinger wrote:
> On 06 Aug 2015 19:52, keld@keldix.com wrote:
> > 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.
> 
> across the world, there are usually multiple changes every year.  sometimes
> with very short notice (weeks or even days).  simply read the history of the
> tzdata package if you want data.  distros updating the timezone database and
> porting it back to older releases is trivial.  patching & pushing glibc
> updates are not.

Well, I don't se why there is a big difference, but maybe you can tell me.

best regards
keld

Re: Removing locale timezone information

[Paul Eggert]

keld@keldix.com wrote:
> I thing tz data changes are not very frequent

No, they're reasonably common: about ten times a year.  For example, yesterday 
North Korea announced they're changing to +0830 on August 15 and we'll generate 
a new tzdata release before then.  We can't reasonably expect glibc releases 
that often or so quickly.

Quick turnaround is important here.  For example, between the time that a new 
tzdata release is announced, and the time my Ubuntu desktop is automatically 
updated with the new data, can be a matter of hours.  (I'm not doing anything 
special; I'm just an ordinary Ubuntu user in this regard.)  This is helpful 
becausee countries sometimes don't give us much notice.  Again, not something 
suited to glibc's schedule.

> are Olson tzdata used in GNU interfaces?

Yes, e.g., in strftime, localtime_r, and tzset.

 > Was there a differnce between German
 > an Swiss timezones? Something with Switzerland not being EU?

Yes, German and Swiss daylight-saving rules disagreed in 1980, and Büsingen 
(which is a German enclave surrounded by the Swiss canton Shaffhausen) used 
Swiss rules.

 > Both your examples are for countries with two timezones

Actually more than two, depending on which version of tzdata you're using. 
China has also had Asia/Chongqing, Asia/Harbin, and Asia/Kashgar in past 
versions.  It may well have more than two in the future.

 > I guess that one of them are the one that the majority will use.

True for China and Germany today, but not for the US, Canada, or Russia.  And in 
several other countries (Australia, Brazil, Indonesia, Mexico, ...) a 
significant minority of users won't want the majority's preference.  We're 
talking about a lot of users here, not just a few exceptional cases.

Re: Removing locale timezone information

[keld]

On Fri, Aug 07, 2015 at 02:03:49PM -0700, Paul Eggert wrote:
> keld@keldix.com wrote:
> >I thing tz data changes are not very frequent
> 
> No, they're reasonably common: about ten times a year.  For example, 
> yesterday North Korea announced they're changing to +0830 on August 15 and 
> we'll generate a new tzdata release before then.  We can't reasonably 
> expect glibc releases that often or so quickly.
> 
> Quick turnaround is important here.  For example, between the time that a 
> new tzdata release is announced, and the time my Ubuntu desktop is 
> automatically updated with the new data, can be a matter of hours.  (I'm 
> not doing anything special; I'm just an ordinary Ubuntu user in this 
> regard.)  This is helpful becausee countries sometimes don't give us much 
> notice.  Again, not something suited to glibc's schedule.

So glibc has no way of making quick corrections appear in distros?
I think most other critical software has a path to have eg security fixes
happen very fast in distros.

> > Both your examples are for countries with two timezones
> 
> Actually more than two, depending on which version of tzdata you're using. 
> China has also had Asia/Chongqing, Asia/Harbin, and Asia/Kashgar in past 
> versions.  It may well have more than two in the future.
> 
> > I guess that one of them are the one that the majority will use.
> 
> True for China and Germany today, but not for the US, Canada, or Russia.  
> And in several other countries (Australia, Brazil, Indonesia, Mexico, ...) 
> a significant minority of users won't want the majority's preference.  
> We're talking about a lot of users here, not just a few exceptional cases.

Agreed, but even for the minority users having just a dozen or so likely
TZ specs to choose from is a good improvement from having
to choose from a long list of TZs  or even choosing by clicking on a map,
as previously explained.

Best regards
keld

Re: Removing locale timezone information

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 3009 bytes --]

keld@keldix.com wrote:
> So glibc has no way of making quick corrections appear in distros?
> I think most other critical software has a path to have eg security fixes
> happen very fast in distros.

It's typically harder to update glibc than to update time zone data.  This is 
partly a matter of size (glibc's files are an order of magnitude larger than 
tzdata's), and partly a matter of release engineering (changing tzdata has far 
fewer security and reliability implications than changing glibc does).  We don't 
want to treat every minor daylight-saving rule change with the same urgency and 
thoroughness as we treat a serious security bug in glibc.  And this is why most 
(perhaps all) GNU/Linux distributions have decoupled tzdata from glibc.

> even for the minority users having just a dozen or so likely
> TZ specs to choose from is a good improvement from having
> to choose from a long list of TZs  or even choosing by clicking on a map,
> as previously explained.

I doubt whether the improvement would be worth the hassle of implementing it. 
Even 'tzselect' wouldn't benefit much, and I expect that the fancier selectors 
would benefit even less as nowadays geoselection is often seamless.

Let me give an example to help put this in context.  Currently 'tzselect' asks 
the user for continent and then country, and then it asks for which time zone in 
that country.  A sample interaction is attached as the first attachment.

If there were an easy way tzselect could ask glibc "What country am I in?" from 
a shell script, tzselect could skip the first two questions asking for continent 
and country, and could simply ask the user to confirm the glibc setting. 
Although that would be a nicety, it's not a high-priority one: nobody has asked 
us for this nicety in two decades of tzselect use.

If in addition glibc locales had the extra information you're proposing, 
tzselect could also derive its third question from that extra information, 
presumably in a localized form rather than tzselect's English-only form (though 
if you look at the transcript you'll see that the "English-only" data is 
stylized and contains many proper names and abbreviations that should be 
reasonably useful to a non-English speaker).  This could be nicer for the user, 
but it would be a pain to maintain and typically geoselection is good enough and 
is considerably easier to maintain as the geo data is locale-agnostic.

For a dumb example of geoselection as implemented in tzselect, see the second 
attachment.  The more-commonly used selectors that can use geo information or 
graphical selection can do a much better job than tzselect does here, and these 
programs wouldn't benefit much from any extra information in glibc locales.

I'm not saying that the extra information would be useless, only that the few 
applications that might use it are so specialized that there are good software 
engineering reasons to put this information into some other package (CLDR, say) 
rather than into glibc.

[-- Attachment #2: tzselect-example.txt --]
[-- Type: text/plain, Size: 2423 bytes --]

$ tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent, ocean, "coord", or "TZ".
 1) Africa
 2) Americas
 3) Antarctica
 4) Arctic Ocean
 5) Asia
 6) Atlantic Ocean
 7) Australia
 8) Europe
 9) Indian Ocean
10) Pacific Ocean
11) coord - I want to use geographical coordinates.
12) TZ - I want to specify the time zone using the Posix TZ format.
#? 2
Please select a country whose clocks agree with yours.
 1) Anguilla		     28) Haiti
 2) Antigua & Barbuda	     29) Honduras
 3) Argentina		     30) Jamaica
 4) Aruba		     31) Martinique
 5) Bahamas		     32) Mexico
 6) Barbados		     33) Montserrat
 7) Belize		     34) Nicaragua
 8) Bolivia		     35) Panama
 9) Brazil		     36) Paraguay
10) Canada		     37) Peru
11) Caribbean Netherlands    38) Puerto Rico
12) Cayman Islands	     39) St Barthelemy
13) Chile		     40) St Kitts & Nevis
14) Colombia		     41) St Lucia
15) Costa Rica		     42) St Maarten (Dutch part)
16) Cuba		     43) St Martin (French part)
17) Curacao		     44) St Pierre & Miquelon
18) Dominica		     45) St Vincent
19) Dominican Republic	     46) Suriname
20) Ecuador		     47) Trinidad & Tobago
21) El Salvador		     48) Turks & Caicos Is
22) French Guiana	     49) United States
23) Greenland		     50) Uruguay
24) Grenada		     51) Venezuela
25) Guadeloupe		     52) Virgin Islands (UK)
26) Guatemala		     53) Virgin Islands (US)
27) Guyana
#? 9
Please select one of the following time zone regions.
 1) Atlantic islands
 2) Amapa, E Para
 3) NE Brazil (MA, PI, CE, RN, PB)
 4) Pernambuco
 5) Tocantins
 6) Alagoas, Sergipe
 7) Bahia
 8) S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC, RS)
 9) Mato Grosso do Sul
10) Mato Grosso
11) W Para
12) Rondonia
13) Roraima
14) E Amazonas
15) W Amazonas
16) Acre
#? 8

The following information has been given:

	Brazil
	S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC, RS)

Therefore TZ='America/Sao_Paulo' will be used.
Local time is now:	Sun Aug  9 12:20:28 BRT 2015.
Universal Time is now:	Sun Aug  9 15:20:28 UTC 2015.
Is the above information OK?
1) Yes
2) No
#? 1

You can make this change permanent for yourself by appending the line
	TZ='America/Sao_Paulo'; export TZ
to the file '.profile' in your home directory; then log out and log in again.

Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
America/Sao_Paulo

[-- Attachment #3: tzselect-geoexample.txt --]
[-- Type: text/plain, Size: 1483 bytes --]

$ tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent, ocean, "coord", or "TZ".
 1) Africa
 2) Americas
 3) Antarctica
 4) Arctic Ocean
 5) Asia
 6) Atlantic Ocean
 7) Australia
 8) Europe
 9) Indian Ocean
10) Pacific Ocean
11) coord - I want to use geographical coordinates.
12) TZ - I want to specify the time zone using the Posix TZ format.
#? 11
Please enter coordinates in ISO 6709 notation.
For example, +4042-07403 stands for
40 degrees 42 minutes north, 74 degrees 3 minutes west.
+5539+01221
Please select one of the following time zone regions,
listed roughly in increasing order of distance from +5539+01221.
1) Denmark			       6) Netherlands
2) Germany - most locations	       7) Czech Republic
3) Norway			       8) Aaland Islands
4) Russia - Moscow-01 - Kaliningrad    9) Poland
5) Sweden			      10) Latvia
#? 1

The following information has been given:

	coord +5539+01221
	Denmark

Therefore TZ='Europe/Copenhagen' will be used.
Local time is now:	Sun Aug  9 17:35:07 CEST 2015.
Universal Time is now:	Sun Aug  9 15:35:07 UTC 2015.
Is the above information OK?
1) Yes
2) No
#? 1

You can make this change permanent for yourself by appending the line
	TZ='Europe/Copenhagen'; export TZ
to the file '.profile' in your home directory; then log out and log in again.

Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
Europe/Copenhagen

Re: Removing locale timezone information

[Zack Weinberg]

On Wed, Aug 12, 2015 at 10:08 AM,  <keld@keldix.com> wrote:
> My impression is that timezone changes are normally announced in due time
> so that they can be included in normal glibc release schedule, which
> I think is about twice a year, but irregulary. I have not been down into
> the data, tho.

Sadly, as pointed out by others, this is not so.

Keld, would your use cases be satisfied if each glibc locale (for
which this makes sense) specified a default *Olsen* timezone?  I think
that might be a way to get what you want while avoiding the problems
everyone else is bringing up.

zw

Re: Removing locale timezone information

[Keld Simonsen]

On Wed, Aug 12, 2015 at 11:06:16AM -0400, Zack Weinberg wrote:
> On Wed, Aug 12, 2015 at 10:08 AM,  <keld@keldix.com> wrote:
> > My impression is that timezone changes are normally announced in due time
> > so that they can be included in normal glibc release schedule, which
> > I think is about twice a year, but irregulary. I have not been down into
> > the data, tho.
> 
> Sadly, as pointed out by others, this is not so.
> 
> Keld, would your use cases be satisfied if each glibc locale (for
> which this makes sense) specified a default *Olsen* timezone?  I think
> that might be a way to get what you want while avoiding the problems
> everyone else is bringing up.

As others has pointed out, there are a number of cases where time zone changes
havd been made with very short notice. I was talking about the normal case,
meaning the majority of cases. I need to go deeper into the data
to see for myself if I should consider myself being wrong. But just mentioning a few cases
do not make my statement false. And my general knowledge
of timezone changes are that they are not frequent. In EU and in the USA and Canada
and big countries in Asia there have been few changes AFAIK in the last few decades, but 
of cause there are many countries and a few changes here and there all adds up.
I will have a look, as suggested.

The suggestion of referencing data in Olson tzdata - I wil investigate that.

Best regards
keld

Re: Removing locale timezone information

[Allan McRae]

On 13/08/15 07:37, Keld Simonsen wrote:
> On Wed, Aug 12, 2015 at 11:06:16AM -0400, Zack Weinberg wrote:
>> On Wed, Aug 12, 2015 at 10:08 AM,  <keld@keldix.com> wrote:
>>> My impression is that timezone changes are normally announced in due time
>>> so that they can be included in normal glibc release schedule, which
>>> I think is about twice a year, but irregulary. I have not been down into
>>> the data, tho.
>>
>> Sadly, as pointed out by others, this is not so.
>>
>> Keld, would your use cases be satisfied if each glibc locale (for
>> which this makes sense) specified a default *Olsen* timezone?  I think
>> that might be a way to get what you want while avoiding the problems
>> everyone else is bringing up.
> 
> As others has pointed out, there are a number of cases where time zone changes
> havd been made with very short notice. I was talking about the normal case,
> meaning the majority of cases. I need to go deeper into the data
> to see for myself if I should consider myself being wrong. But just mentioning a few cases
> do not make my statement false. And my general knowledge
> of timezone changes are that they are not frequent. In EU and in the USA and Canada
> and big countries in Asia there have been few changes AFAIK in the last few decades, but 
> of cause there are many countries and a few changes here and there all adds up.
> I will have a look, as suggested.

I can remember having to ship a tzdata package fast due to last minute
DST changes for somewhere in the USA.  Even if it is the minority of
cases, this makes using glibc for this information rather than tzdata
very difficult for a Linux distribution.

Allan

Re: Removing locale timezone information

[Paul Eggert]

keld@keldix.com wrote:

> My impression is that timezone changes are normally announced in due time
> so that they can be included in normal glibc release schedule, which
> I think is about twice a year, but irregulary.

No, that's incorrect.  We sometimes get only a few days' notice.  For tomorrow's 
change in North Korea, we got one week's notice.  We released a new tz version 
Monday.  We average about ten releases a year.

>> If there were an easy way tzselect could ask glibc "What country am I in?"
>> from a shell script

> Oh well, specs to do it has been available for something like 2 decades in 14652.

How can a time-oriented shell script use 14652 to ask "What country am I in?", 
preferably getting a 2-letter code?  I don't see anything in 14652's description 
of LC_TIME that would help an application discover what country the 
application's clocks should be set to.

Also, in 14652 LC_TIME's timezone keyword doesn't provide for TZ settings like 
'America/Los_Angeles' or 'Europe/Berlin' that are quite common in practice and 
are more useful than POSIX TZ settings.  So it doesn't appear that the 
14652-standardized info would be of much use to tzselect.

> I would much rather have users pick the
> locale, and then present them with some defaults, that then can be changed
> if necessary. And if geoip is available, then present a default
> and likely selection of locales based on that.

Certainly geolocation helps, but how would this be put into a glibc-style 
locale?  14652 doesn't provide for geolocation.  Most modern apps support TZ 
selection by maintaining their own geographical databases.  If it's really the 
intent to move this info into the locale, it sounds like a big project.

Once one has geolocation, the older selection mechanisms seem clumsy and 
outdated and really, not worth spending much time on.  So not only were the 
recently-removed timezone entries in glibc locales unused and woefully 
incomplete, application writers typically don't want that particular info anyway.

If (despite all my discouragment :-) you still want to improve locale timezone 
support for old-fashioned non-geolocation applications, I like Zack Weinberg's 
suggestion.  From tzselect's point of view, it'd be mildly helpful if a shell 
script could get a list of plausible TZ settings for the current locale, along 
with an informal description of each setting so that non-expert users could make 
an informed choice.  tzselect is already doing this now with its own database, 
but if glibc locales provided that information instead I suppose tzselect could 
use it.

Re: Removing locale timezone information

[Andreas Schwab]

keld@keldix.com writes:

> My impression is that timezone changes are normally announced in due time

You mean like this?

<http://permalink.gmane.org/gmane.comp.time.tz/9449>
<http://permalink.gmane.org/gmane.comp.time.tz/9802>

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Removing locale timezone information

[Allan McRae]

On 13/08/15 00:08, keld@keldix.com wrote:
> On Sun, Aug 09, 2015 at 08:52:31AM -0700, Paul Eggert wrote:
>> keld@keldix.com wrote:
>>> So glibc has no way of making quick corrections appear in distros?
>>> I think most other critical software has a path to have eg security fixes
>>> happen very fast in distros.
>>
>> It's typically harder to update glibc than to update time zone data.  This 
>> is partly a matter of size (glibc's files are an order of magnitude larger 
>> than tzdata's), and partly a matter of release engineering (changing tzdata 
>> has far fewer security and reliability implications than changing glibc 
>> does).  We don't want to treat every minor daylight-saving rule change with 
>> the same urgency and thoroughness as we treat a serious security bug in 
>> glibc.  And this is why most (perhaps all) GNU/Linux distributions have 
>> decoupled tzdata from glibc.
> 
> My impression is that timezone changes are normally announced in due time
> so that they can be included in normal glibc release schedule, which
> I think is about twice a year, but irregulary. I have not been down into
> the data, tho.

I can recall a couple of occasions where there was a very short notice.
 e.g. last week, North Korea changed its timezone, effective on the 15th.

Going through the archives of tz-announce [1], shows plenty of short
notice changes.

It seems you should look at actual data before making these assertions.

Allan

[1] http://mm.icann.org/pipermail/tz-announce/

Re: Removing locale timezone information

[Paul Eggert]

Marko Myllynen wrote:
> 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

Sounds reasonable to me.

I don't know of anybody using the glibc version of this data.  The existing 
entries duplicate a small part of tzdata, except for two points of disagreement 
where I'd guess they're less correct than tzdata.  First, the UA abbreviations 
"з.ч." and "л.ч." are simply Ukrainian abbreviations for "Зимовий час" and 
"Літній час", which is not right, as it's supposed to be a time zone 
abbreviation, not an ST/DST abbreviation.  Second, the TW abbreviation "TST" is 
unusual in Taiwan -- though "Taiwan Standard Time" has been used, the most 
common Latin-alphabet abbreviation is probably "CST" (there are some complicated 
politics going on here, for obvious reasons -- among other things there doesn't 
seem to be any offical published name or abbreviation for the time zone in 
Taiwan because the politics of choosing a name are too tricky).

[PATCH] Remove locale timezone information

[Marko Myllynen]

Hi,

as discussed in the thread starting at

https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html

it looks like the best options is to remove locale timezone information
from locales which currently provide it (in incomplete or incorrect
fashion) rather than to start duplicating tzdata info in glibc.

2015-06-12  Marko Myllynen  <myllynen@redhat.com>

	[BZ #18525]
	* locales/km_KH: Remove timezone definition.
	* locales/lo_LA: Likewise.
	* locales/my_MM: Likewise.
	* locales/nan_TW@latin: Likewise.
	* locales/th_TH: Likewise.
	* locales/uk_UA: Likewise.

diff --git a/localedata/locales/km_KH b/localedata/locales/km_KH
index 5563659..aaef20d 100644
--- a/localedata/locales/km_KH
+++ b/localedata/locales/km_KH
@@ -1838,8 +1838,6 @@ am_pm    "<U1796><U17D2><U179A><U17B9><U1780>";"<U179B><U17D2><U1784><U17B6><U17
 %date_fmt       "<U0025><U0061><U0020><U0025><U0065><U0020><U0025><U0062>/
 %<U0020><U0025><U0045><U0079><U0020><U0025><U0048><U003A><U0025><U004D>/
 %<U003A><U0025><U0053><U0020><U0025><U005A>"
-% ICT-7ICT-7
-%timezone	"<U0049><U0043><U0054><U002D><U0037><U0049><U0043><U0054><U002d><U0037>"
 
 END LC_TIME
 
diff --git a/localedata/locales/lo_LA b/localedata/locales/lo_LA
index c584877..eba90ce 100644
--- a/localedata/locales/lo_LA
+++ b/localedata/locales/lo_LA
@@ -716,8 +716,6 @@ era_d_t_fmt     "<U0EA7><U0EB1><U0E99>%A<U0E97><U0EB5><U0EC8><U0020>%e<U0020>%B<
 date_fmt       "<U0025><U0061><U0020><U0025><U0065><U0020><U0025><U0062>/
 <U0020><U0025><U0045><U0079><U0020><U0025><U0048><U003A><U0025><U004D>/
 <U003A><U0025><U0053><U0020><U0025><U005A>"
-% ICT-7ICT-7
-timezone	"<U0049><U0043><U0054><U002D><U0037><U0049><U0043><U0054><U002d><U0037>"
 END LC_TIME
 
 LC_MESSAGES
diff --git a/localedata/locales/my_MM b/localedata/locales/my_MM
index d9a2db1..165519a 100644
--- a/localedata/locales/my_MM
+++ b/localedata/locales/my_MM
@@ -157,9 +157,6 @@ t_fmt       "<U0025><U004F><U0049><U003A><U0025><U004F><U004D><U003A><U0025><U00
 % %OI:%OM:%OS %p
 t_fmt_ampm  "<U0025><U004F><U0049><U003A><U0025><U004F><U004D><U003A><U0025><U004F><U0053><U0020><U0025><U0070>"
 
-% MMT-6.5MMT-6.5
-timezone "<U004D><U004D><U0054><U002D><U0036><U002E><U0035><U004D><U004D><U0054><U002D><U0036><U002E><U0035>"
-
 alt_digits  "<U1040><U1040>";/
 		"<U1040><U1041>";/
 		"<U1040><U1042>";/
diff --git a/localedata/locales/nan_TW@latin b/localedata/locales/nan_TW@latin
index a1e7d49..eb2b292 100644
--- a/localedata/locales/nan_TW@latin
+++ b/localedata/locales/nan_TW@latin
@@ -136,7 +136,6 @@ d_fmt       "<U0025><U0046>"
 t_fmt       "<U0025><U0072>"
 am_pm       "<U0074><U00E9><U006E><U0067><U002D><U0070><U006F><U0358>";"<U0113><U002D><U0070><U006F><U0358>"
 t_fmt_ampm  "<U0025><U0049><U003A><U0025><U004D><U003A><U0025><U0053><U0020><U0025><U0070>"
-timezone    "<U0054><U0053><U0054><U002D><U0038>"
 date_fmt    "<U0025><U0059><U0020><U0025><U0062><U0020><U0025><U0064><U0020><U0028><U0025><U0061><U0029><U0020><U0025><U0048><U003A><U0025><U004D><U003A><U0025><U0053><U0020><U0025><U005A>"
 END LC_TIME
 
diff --git a/localedata/locales/th_TH b/localedata/locales/th_TH
index 88c3637..5b8c41b 100644
--- a/localedata/locales/th_TH
+++ b/localedata/locales/th_TH
@@ -911,8 +911,6 @@ era_d_t_fmt     "<U0E27><U0E31><U0E19>%A<U0E17><U0E35><U0E48><U0020>%e<U0020>%B<
 date_fmt       "<U0025><U0061><U0020><U0025><U0065><U0020><U0025><U0062>/
 <U0020><U0025><U0045><U0079><U0020><U0025><U0048><U003A><U0025><U004D>/
 <U003A><U0025><U0053><U0020><U0025><U005A>"
-% ICT-7ICT-7
-timezone	"<U0049><U0043><U0054><U002D><U0037><U0049><U0043><U0054><U002d><U0037>"
 END LC_TIME
 
 LC_MESSAGES
diff --git a/localedata/locales/uk_UA b/localedata/locales/uk_UA
index 511f004..5e58043 100644
--- a/localedata/locales/uk_UA
+++ b/localedata/locales/uk_UA
@@ -964,31 +964,6 @@ first_weekday 2
 % Define the first workday relative to the <week> keyword
 first_workday 2
 
-% Zymovyj CHas (winter time) or z.ch. (or nothing)
-% Litnij CHas (summer time) or l.ch.
-%
-% ( or EET/EEST (Easter Europe [Summer] Time) )
-% ( or Europe/Kyiv (or Kiev, in Russian) )
-%
-% Format:
-%
-% <ZoneName><Offset><ZoneName><Offset>,<rule>,<rule>[,...]
-%
-%  ZoneName - at least 3 letters, up to 10
-%  Offset - (+|-)hh[:mm[:ss]]
-%     - - time zone is east of Prime Meridian
-%     + - time zone is west of Prime Meridian
-%  rule: <date>[/time[/year]]
-%   date:
-%     J<JulianDay> , 1-365 (without 29.02)
-%     <JulianDay> , 0-364 (without 29.02)
-%     M<m>.<n>.<d> - m - month(1-12)
-%                    n - week(1-5)
-%                    d - day of week(0-7), day zero and day seven is Sunday
-%   time - the same as <offset> (but without leading +/-)
-%
-timezone "<U0437><U002E><U0447><U002E><U002D><U0030><U0032><U003A><U0030><U0030><U043B><U002E><U0447><U002E><U002D><U0030><U0033><U003A><U0030><U0030><U002C><U004D><U0033><U002E><U0035><U002E><U0030><U002F><U0030><U0033><U003A><U0030><U0030><U002C><U004D><U0031><U0030><U002E><U0035><U002E><U0030><U002F><U0030><U0034><U003A><U0030><U0030>"
-
 % Example:
 %
 %           traven`         cherven`

Thanks,

-- 
Marko Myllynen

Re: [PATCH] Remove locale timezone information

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On 12 Jun 2015 17:05, Marko Myllynen wrote:
> as discussed in the thread starting at
> 
> https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
> 
> it looks like the best options is to remove locale timezone information
> from locales which currently provide it (in incomplete or incorrect
> fashion) rather than to start duplicating tzdata info in glibc.

thanks, pushed now!
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 05:07:48AM -0400, Mike Frysinger wrote:
> On 12 Jun 2015 17:05, Marko Myllynen wrote:
> > as discussed in the thread starting at
> > 
> > https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
> > 
> > it looks like the best options is to remove locale timezone information
> > from locales which currently provide it (in incomplete or incorrect
> > fashion) rather than to start duplicating tzdata info in glibc.
> 
> thanks, pushed now!
> -mike

That is the wrong direction. Please revert the change.

Best regarrds
Keld

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 12:01:26PM +0200, keld@keldix.com wrote:
> On Wed, Aug 05, 2015 at 05:07:48AM -0400, Mike Frysinger wrote:
> > On 12 Jun 2015 17:05, Marko Myllynen wrote:
> > > as discussed in the thread starting at
> > > 
> > > https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
> > > 
> > > it looks like the best options is to remove locale timezone information
> > > from locales which currently provide it (in incomplete or incorrect
> > > fashion) rather than to start duplicating tzdata info in glibc.
> > 
> > thanks, pushed now!
> > -mike
> 
> That is the wrong direction. Please revert the change.

Let me explain. We would like to make the installation process easier
for users. That is, if we can remove one more question under the installation
process of linux, that would be a  goal. If the timezone is fully determined
by the choice of locale, then there is no need to ask for the timezone.

Currently the timezone is often determined by a click on a map, which is quite
error prone, because the world is big and it is hard to hit the right place.
That process is also time consuming. Some users omit the step,
just using the default, which is often wrong.

Furthermore it is not politically correct timezone information in these apps,
they give the time zone as a city name, which is quite politicalle problematic
There is a growing political uproar against the big cities and the associated
political powers. We just had an elelction here in Denmark where this issue
(Not Linux locale names, but country vs the capital:-) were probably the most
defining issue. Also think of the USA with Washington DC against rural America.

For countries with more timezones, the locale data helps narrowing down the
choices. And there are not that many countries with more than 1 timezone,
eg USA, Canada, Russia and Greenland. Many big countries like China and India
only have 1 timezone , and the countries in Europe and Africa and South America
and Asia almost all have only 1 timezone.

So the locale timezone info helps doing an easier job - and also a more culturally
acceptable job. I hope we are all for going in that direction.

Best regards
keld

Re: [PATCH] Remove locale timezone information

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

On 05 Aug 2015 12:22, keld@keldix.com wrote:
> On Wed, Aug 05, 2015 at 12:01:26PM +0200, keld@keldix.com wrote:
> > On Wed, Aug 05, 2015 at 05:07:48AM -0400, Mike Frysinger wrote:
> > > On 12 Jun 2015 17:05, Marko Myllynen wrote:
> > > > as discussed in the thread starting at
> > > > 
> > > > https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
> > > > 
> > > > it looks like the best options is to remove locale timezone information
> > > > from locales which currently provide it (in incomplete or incorrect
> > > > fashion) rather than to start duplicating tzdata info in glibc.
> > > 
> > > thanks, pushed now!
> > 
> > That is the wrong direction. Please revert the change.
> 
> Let me explain. We would like to make the installation process easier
> for users. That is, if we can remove one more question under the installation
> process of linux, that would be a  goal. If the timezone is fully determined
> by the choice of locale, then there is no need to ask for the timezone.

having 6 out of 300+ locales define timezone info is not something people can 
rely on.  we also don't want to duplicate data that is *actively* maintained
elsewhere (the tz lists).  plus many locales span multiple timezones.

i don't see crappy UIs as a problem glibc either can or should solve.  at the
end of the day, trying to set the timezone based on the locale isn't going to
cover everyone (even a significant number of people), especially as you move
around.  i certainly don't want it being tied to my locale.  which means UIs
are required to get this right.

if you want to bring timezone data into the locale fields, then it should be
done consistently across the board and in a maintainable manner.  until that
happens, having data in a measly 6 locales is more of a disservice imo.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 06:53:11AM -0400, Mike Frysinger wrote:
> On 05 Aug 2015 12:22, keld@keldix.com wrote:
> > On Wed, Aug 05, 2015 at 12:01:26PM +0200, keld@keldix.com wrote:
> > > On Wed, Aug 05, 2015 at 05:07:48AM -0400, Mike Frysinger wrote:
> > > > On 12 Jun 2015 17:05, Marko Myllynen wrote:
> > > > > as discussed in the thread starting at
> > > > > 
> > > > > https://sourceware.org/ml/libc-alpha/2015-06/msg00098.html
> > > > > 
> > > > > it looks like the best options is to remove locale timezone information
> > > > > from locales which currently provide it (in incomplete or incorrect
> > > > > fashion) rather than to start duplicating tzdata info in glibc.
> > > > 
> > > > thanks, pushed now!
> > > 
> > > That is the wrong direction. Please revert the change.
> > 
> > Let me explain. We would like to make the installation process easier
> > for users. That is, if we can remove one more question under the installation
> > process of linux, that would be a  goal. If the timezone is fully determined
> > by the choice of locale, then there is no need to ask for the timezone.
> 
> having 6 out of 300+ locales define timezone info is not something people can 
> rely on.

Well, it takes time to build the info. Furthermore, if data is not available
they can always fall back to the TZ info. This is all spelled out in the standard.

> we also don't want to duplicate data that is *actively* maintained
> elsewhere (the tz lists). 

The relation between tz and country is not maintained anywhere else, except in some
distributions, AFAIK.

Anyway many of the data in locales are just duplication
of data maintained elsewhere. That is the main purpose of a locale, to collect
data that are often maintained elsewhere, in a big bundle so that a user
can easily select that big bundle for his/her environment.

> plus many locales span multiple timezones.

How many? I think it is not a majority (by far). Anyway, as I explained,
even if there are more timezone choices for a locale, then it is an improvement
to have the choices instead of a cumbersome clicking on a map, which selects
Washington DC or New York as a default (sic!)

> i don't see crappy UIs as a problem glibc either can or should solve.  at the
> end of the day,

Ultimately glibc implements functionality that is benefitting the end user.
This data has one of its foremost usefulness in setting timezone info.

> trying to set the timezone based on the locale isn't going to
> cover everyone (even a significant number of people),

Most of the world would be covered.  A quick calculation: countries with more than
1 timezone: USA, Canada, Mexico, Greenland, Brazil, Russia, Australia.
In total about 800 mill people out of a world polulation of 7000 mill.
And for many of these countries, the choice is only between 2 or 3 zones,
ag: Brazil, Mexico, Greenland, Australia.
The only real problmatic countries are USA, Canada and Russia.

> especially as you move
> around.  i certainly don't want it being tied to my locale.  which means UIs
> are required to get this right.

Most people don't move. But if you travel, you can easily change timezone.
I regularily do that.

> if you want to bring timezone data into the locale fields, then it should be
> done consistently across the board and in a maintainable manner.  until that
> happens, having data in a measly 6 locales is more of a disservice imo.

It is a beginning, and instead of just removing it, I think we should rather
encourage this, and even set out to have an overall collection of the data.
Furthermore, the data does not harm, if it is correct.  It can be used as
explained in the standard, even if the data is only available for a few
countries, and there is a clear migration path specified.

Best regards
Keld

Re: [PATCH] Remove locale timezone information

[Andreas Schwab]

keld@keldix.com writes:

> Well, it takes time to build the info. Furthermore, if data is not available
> they can always fall back to the TZ info. This is all spelled out in the standard.

The TZ info isn't a fallback, the POSIX timezone is.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 02:33:02PM +0200, Andreas Schwab wrote:
> keld@keldix.com writes:
> 
> > Well, it takes time to build the info. Furthermore, if data is not available
> > they can always fall back to the TZ info. This is all spelled out in the standard.
> 
> The TZ info isn't a fallback, the POSIX timezone is.

I was talking about ISO TR 30112 LC_TIME timezone spec. The TZ environment variable
overrides the LC_TIME timezone spec.

Best regards
keld

Re: [PATCH] Remove locale timezone information

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On 05 Aug 2015 13:30, keld@keldix.com wrote:
> On Wed, Aug 05, 2015 at 06:53:11AM -0400, Mike Frysinger wrote:
> > having 6 out of 300+ locales define timezone info is not something people can 
> > rely on.
> 
> Well, it takes time to build the info.

how much time exactly do you think is reasonable ?  it's been more than 10 years 
and clearly no one thus far cares enough to drive this.  if you do, then feel 
free, but until that happens i see no reason to restore the incomplete data.

> How many? I think it is not a majority (by far).

seeing as how people literally travel around the world now, and mobility is only 
increasing, any combo is fair game now.

> Anyway, as I explained,
> even if there are more timezone choices for a locale, then it is an improvement
> to have the choices instead of a cumbersome clicking on a map, which selects
> Washington DC or New York as a default (sic!)

which is why there's been a rise to use packages like geoip to automatically 
detect an appropriate region based on the network connectivity, gps, cellular
stations, or other sources.

i've just snipped the rest because none of the responses i found convincing
and rehashing things is going nowhere.  sorry.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Remove locale timezone information

[Keld Simonsen]

On Wed, Aug 05, 2015 at 09:33:05AM -0400, Mike Frysinger wrote:
> On 05 Aug 2015 13:30, keld@keldix.com wrote:
> > On Wed, Aug 05, 2015 at 06:53:11AM -0400, Mike Frysinger wrote:
> > > having 6 out of 300+ locales define timezone info is not something people can 
> > > rely on.
> > 
> > Well, it takes time to build the info.
> 
> how much time exactly do you think is reasonable ?  it's been more than 10 years 
> and clearly no one thus far cares enough to drive this.  if you do, then feel 
> free, but until that happens i see no reason to restore the incomplete data.

Yes, it has taken quite a long time. Maybe because the locales that people build on
do not have timezone info, and maybe because 14652 timezone syntax was not supported by
glibc, including DST history changes.

I don't know. I think I could add timezone info since the epoch based on
the Olson data for each of the locales. Would you be positive about committing such changes 
Mike?  I would then have to write up a program for that.

Do we use Olson tz data in any of the  glibc functions?

> > How many? I think it is not a majority (by far).
> 
> seeing as how people literally travel around the world now, and mobility is only 
> increasing, any combo is fair game now.

Why is changing the timezone in an app not a satisfactory way of handling this?

You must acknowledge that the multiple timezone per country is a quite limited problem,
only really valid for the USA, Canada and Russia. I don't know where you are from,
but could you consider that it would be an improvement for the vast majority of the
world, even if it was not as great for you?

Anyway using geoip could solve part of this, as you note below.
But when you travel, you normally would like to retain most of your environment
such as the language, only TZ info would need to change.

> > Anyway, as I explained,
> > even if there are more timezone choices for a locale, then it is an improvement
> > to have the choices instead of a cumbersome clicking on a map, which selects
> > Washington DC or New York as a default (sic!)
> 
> which is why there's been a rise to use packages like geoip to automatically 
> detect an appropriate region based on the network connectivity, gps, cellular
> stations, or other sources.

Yes, that is a good way forward but for initial setup of a machine, one still
would need the coupling on the geoip data with a locale, and then the coupling 
of a locale to a timezone. So still the  timezone info coupled to the locale 
is very useful.

> i've just snipped the rest because none of the responses i found convincing
> and rehashing things is going nowhere.  sorry.

Well, also sorry that we don't agree on the purpose of glibc,  and on making the life of 
end users easier, and making time display correct.  It also seems like we have different
ways of counting the people in the world, or at least giving importance to them.

Best regards
Keld

Re: [PATCH] Remove locale timezone information

[Joseph Myers]

On Wed, 5 Aug 2015, Keld Simonsen wrote:

> I don't know. I think I could add timezone info since the epoch based on
> the Olson data for each of the locales. Would you be positive about committing such changes 
> Mike?  I would then have to write up a program for that.

We should not duplicate the work done externally in tracking timezone 
changes, nor embed copies of such frequently changing data in glibc (the 
existing copies of timezone data are purely for use as test inputs for zic 
and time-related functions, not for installation).

I don't think it's useful to embed Olson timezone names in glibc locales 
either.  Rather, location-selection mechanisms maintained entirely outside 
glibc should provide user-friendly ways of choosing both (language, 
country) locale rules and timezone (the latter might change when 
travelling, the former probably not).

Olson timezone names are explicitly not intended to be presented directly 
to users for timezone selection.  See the Theory file 
<https://github.com/eggert/tz/blob/master/Theory>.  If a distribution is 
presenting such names (and thus causing issues because the named city is 
politically inappropriate), report it as a bug directly to that 
distribution.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Remove locale timezone information

[Keld Simonsen]

On Wed, Aug 05, 2015 at 04:15:14PM +0000, Joseph Myers wrote:
> On Wed, 5 Aug 2015, Keld Simonsen wrote:
> 
> > I don't know. I think I could add timezone info since the epoch based on
> > the Olson data for each of the locales. Would you be positive about committing such changes 
> > Mike?  I would then have to write up a program for that.
> 
> We should not duplicate the work done externally in tracking timezone 
> changes, nor embed copies of such frequently changing data in glibc (the 
> existing copies of timezone data are purely for use as test inputs for zic 
> and time-related functions, not for installation).

I don't understand your attitude here. Most other data in locales are
coming from somewhere else, such as the language codes, the country codes,
the date formats, the character attributes, the collation sequence.

Locales are just a way of providing all these data, collected from
different sources, into one uniform syntax, to be utilized by
different glibc functions. And also collected so the user
can choose the whole collection in one go. That has proven a useful
concept for many years in the POSIX/C environment.

Best regards
Keld

Re: [PATCH] Remove locale timezone information

[Andreas Schwab]

Keld Simonsen <keld@keldix.com> writes:

> Locales are just a way of providing all these data, collected from
> different sources, into one uniform syntax, to be utilized by
> different glibc functions. And also collected so the user
> can choose the whole collection in one go. That has proven a useful
> concept for many years in the POSIX/C environment.

And the timezone package it the primary source for timezone data.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] Remove locale timezone information

[Zack Weinberg]

Is it possible for a locale to specify an Olson timezone which will be
used *as the default* (i.e. unless overridden by TZ=) ?  If that were
possible, then it would be straightforward to label most locales with
an appropriate timezone and there would be no issue of having to
maintain the same information in two places.

On Thu, Aug 6, 2015 at 2:44 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Keld Simonsen <keld@keldix.com> writes:
>
>> Locales are just a way of providing all these data, collected from
>> different sources, into one uniform syntax, to be utilized by
>> different glibc functions. And also collected so the user
>> can choose the whole collection in one go. That has proven a useful
>> concept for many years in the POSIX/C environment.
>
> And the timezone package it the primary source for timezone data.
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."

Re: [PATCH] Remove locale timezone information

[Joseph Myers]

On Thu, 6 Aug 2015, Keld Simonsen wrote:

> On Wed, Aug 05, 2015 at 04:15:14PM +0000, Joseph Myers wrote:
> > On Wed, 5 Aug 2015, Keld Simonsen wrote:
> > 
> > > I don't know. I think I could add timezone info since the epoch based on
> > > the Olson data for each of the locales. Would you be positive about committing such changes 
> > > Mike?  I would then have to write up a program for that.
> > 
> > We should not duplicate the work done externally in tracking timezone 
> > changes, nor embed copies of such frequently changing data in glibc (the 
> > existing copies of timezone data are purely for use as test inputs for zic 
> > and time-related functions, not for installation).
> 
> I don't understand your attitude here. Most other data in locales are
> coming from somewhere else, such as the language codes, the country codes,
> the date formats, the character attributes, the collation sequence.

tzdata is updated many times a year, sometimes with no more than a few 
days' notice that a country is changing its timezone; I don't think 
countries change their collation rules with a few days' notice like that.  
GNU/Linux distributions have well-established processes for getting those 
updates out to users in a timely manner.  Note that tzdata comes from 
separate sources to glibc, and is built independently of glibc; anything 
built from the glibc source tree would be liable to require other binary 
packages built from the same source tree to be updated at the same time, 
which is not helpful.

A few years ago we deliberately stopped installing timezone data from 
glibc because it was much better for distributions to get the updates 
directly from the upstream project.  The principles haven't changed.

It's possible the tzdist protocol may become relevant in future for this 
purpose, or that glibc might gain support for rereading timezone data in 
future (relevant for long-running processes when timezone rules change).  
But I don't see timezone information in locales as being relevant to glibc 
in the future.  The path that leads to systems where timezone information 
in locales is relevant is a path that diverged from glibc (and Unix-like 
systems in general) a long time ago (over 20 years ago, at least, given 
how POSIX had separate interfaces for timezones and locales over 20 years 
ago and the tz database dates back to 1986 or before.

Timezones and locales are completely orthogonal in glibc.  Moving away 
from that would be a backwards step.  If anything, we should add 
interfaces involving explicit timezone objects (see bug 17651) just like 
the interfaces involving explicit locale objects to make it even more 
convenient for applications to use arbitrary combinations of locales and 
timezones when processing data where different records may involve 
different timezones.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] Remove locale timezone information

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

On 05 Aug 2015 17:56, Keld Simonsen wrote:
> or at least giving importance to them.

please, cut the crap
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Remove locale timezone information

[Andreas Schwab]

keld@keldix.com writes:

> Let me explain. We would like to make the installation process easier
> for users. That is, if we can remove one more question under the installation
> process of linux, that would be a  goal. If the timezone is fully determined
> by the choice of locale, then there is no need to ask for the timezone.

To make this useful the locale would need to use the Olson name, not the
POSIX name of the timezone.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 12:37:08PM +0200, Andreas Schwab wrote:
> keld@keldix.com writes:
> 
> > Let me explain. We would like to make the installation process easier
> > for users. That is, if we can remove one more question under the installation
> > process of linux, that would be a  goal. If the timezone is fully determined
> > by the choice of locale, then there is no need to ask for the timezone.
> 
> To make this useful the locale would need to use the Olson name, not the
> POSIX name of the timezone.

Olson names are problematic, as they are not culturally acceptable in many
cases, as I explained. This is a big issue a number of places, including 
my country, Denmark, and probably also the USA.

In my country this issue is so big that many people refuse to talk about
other issues. I am myself from the Copenhagen area, so I am frustrated about this
being an obstacle to discuss "real" problems.

Furthermore, Olsen TZ data does not allow for DST changes over years, while the 
locale timezone data do allow this, providing correct time display for
also older data, including in the USA, where the DST change was changed from
end of September to end of October at some point. This also
happened many places in Europe. 

Best regards
keld

Re: [PATCH] Remove locale timezone information

[Andreas Schwab]

keld@keldix.com writes:

> Furthermore, Olsen TZ data does not allow for DST changes over years, while the 
> locale timezone data do allow this, providing correct time display for
> also older data, including in the USA, where the DST change was changed from
> end of September to end of October at some point. This also
> happened many places in Europe. 

??? It's exactly the other way round.  The POSIX timezone has no
history.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 02:27:04PM +0200, Andreas Schwab wrote:
> keld@keldix.com writes:
> 
> > Furthermore, Olsen TZ data does not allow for DST changes over years, while the 
> > locale timezone data do allow this, providing correct time display for
> > also older data, including in the USA, where the DST change was changed from
> > end of September to end of October at some point. This also
> > happened many places in Europe. 
> 
> ??? It's exactly the other way round.  The POSIX timezone has no
> history.

True, POSIX has no history, but I was talking about ISO TR 14652 and 30112, which have history.
And I see that Olson tx data has history, but not in a format compatible with POSIX TZ.

best regards
keld

Re: [PATCH] Remove locale timezone information

[Paul Eggert]

On 08/05/2015 03:22 AM, keld@keldix.com wrote:
> For countries with more timezones, the locale data helps narrowing down the
> choices. And there are not that many countries with more than 1 timezone,
> eg USA, Canada, Russia and Greenland. Many big countries like China and India
> only have 1 timezone

Actually, China has two time zones: tzdata's Asia/Shanghai and 
Asia/Urumqi both reflect officially-kept time.  Even Germany has more 
than one tzdata entry, due to the a difference in post-1970 history of 
timekeeping in its Swiss enclaves.  So the problem of many time zones 
for one locale is bigger than what you're suggesting, even if we ignore 
traveling users (which is a pretty big class to ignore).

As for tzdata names "not being culturally acceptable", they are intended 
for use as internal identifiers, visible to experts like us but not to 
end users, so "cultural acceptability" should not be an issue.  End 
users in China, for example, are not expected to see "Asia/Shanghai" 
even in an English locale, but instead are expected to see "China 
Standard Time" or "Beijing Time" or something like that.  Strings like 
"China Standard Time" and "北京时间" are maintained by the Unicode 
Common Locale Data Repository <http://cldr.unicode.org/> and are widely 
used in glibc-based systems.  I don't know whether CLDR supports ISO TR 
14652 and 30112, but if it doesn't then I suggest approaching the CLDR 
maintainers.

Re: [PATCH] Remove locale timezone information

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

On 05 Aug 2015 09:20, Paul Eggert wrote:
> On 08/05/2015 03:22 AM, keld@keldix.com wrote:
> > For countries with more timezones, the locale data helps narrowing down the
> > choices. And there are not that many countries with more than 1 timezone,
> > eg USA, Canada, Russia and Greenland. Many big countries like China and India
> > only have 1 timezone
> 
> Actually, China has two time zones: tzdata's Asia/Shanghai and 
> Asia/Urumqi both reflect officially-kept time.  Even Germany has more 
> than one tzdata entry, due to the a difference in post-1970 history of 
> timekeeping in its Swiss enclaves.  So the problem of many time zones 
> for one locale is bigger than what you're suggesting, even if we ignore 
> traveling users (which is a pretty big class to ignore).

a cursory search shows many more countries as well:
Canada, USA, Mexico, Brazil, Australia, Russia, Mongolia, Kazakhstan,
Democratic Republic of Congo, Indonesia, Greenland (does that mean Denmark
too?).  that's at least 16% of the world's population (35% if you count
China).

and that's just for the current period of time.  as you highlight, if you
look back historically, there are other countries that spanned timezones.

locales also are not strictly defined by country borders which means the
timezone spans are even higher (i'm not counting people who travel).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 10:56:44PM -0400, Mike Frysinger wrote:
> On 05 Aug 2015 09:20, Paul Eggert wrote:
> > On 08/05/2015 03:22 AM, keld@keldix.com wrote:
> > > For countries with more timezones, the locale data helps narrowing down the
> > > choices. And there are not that many countries with more than 1 timezone,
> > > eg USA, Canada, Russia and Greenland. Many big countries like China and India
> > > only have 1 timezone
> > 
> > Actually, China has two time zones: tzdata's Asia/Shanghai and 
> > Asia/Urumqi both reflect officially-kept time.  Even Germany has more 
> > than one tzdata entry, due to the a difference in post-1970 history of 
> > timekeeping in its Swiss enclaves.  So the problem of many time zones 
> > for one locale is bigger than what you're suggesting, even if we ignore 
> > traveling users (which is a pretty big class to ignore).
> 
> a cursory search shows many more countries as well:
> Canada, USA, Mexico, Brazil, Australia, Russia, Mongolia, Kazakhstan,
> Democratic Republic of Congo, Indonesia, Greenland (does that mean Denmark
> too?).  that's at least 16% of the world's population (35% if you count
> China).

I am glad you are now coming forward with actual facts, Mike.
Then we can hopefully find out what the facts are, and probably agree on something.
I have previously done discussion with people were we were intially 
in violent diagreement, but along the road I got a little wiser and probably
my opponent also got a little wiser, and we found some workable solutions. 
That is why I keep responding to almost all of pour posts in a technical
tone, and I hope you could do the same, for the benefit of the glibc project.

I have as you may know been involved with glibc i18n for many years,
and I designed and speced many of the i18n enhancements over POSIX/C,
and also provided lots of data for that purpose to the glibc project.
If I am not corrected with my futurisic ideas, I will probably continue infinitely
on this path - till now it has led us much of the way to where we are now.

Most of these countries I have already mentioned in previous posts.
For Greenland, yes, it is part of the Kingdom of Denmark, but not part
of the State of Denmark. Greenland has its own country code, and
thus its own locales.

I also mentioned in previous posts that narrowing the choice of locales down to
two or three is a big improvement over the current state, even if you cannot 
fully determine a locale for a country. Do you think there is any merit in that
observation, Mike?

My conclusion was then that the only countries that did not benefit 
hugely on the narrow range of plausible locales were the USA, Canada and Russia.
But anyway, having to chose between about a dozen different locales that can be presented 
in one display, is a much nicer option than chosing amongst a long list of all glibc
locales.

> and that's just for the current period of time.  as you highlight, if you
> look back historically, there are other countries that spanned timezones.

Yes, the Olson tz database probably has all these data. 
Still, if you order the timezones for a country in some way, eg order of population,
or alphabetically, you could probably find a solution that is useful to most
people. And then you have the option of setting a specific
TZ variable if you have someting really special. This is UNIX, you know,
we can tweek it endlessly.

> locales also are not strictly defined by country borders which means the
> timezone spans are even higher (i'm not counting people who travel).

I doubt this is a big case. And anyway it can be tweeked, as noted above, right?

best regards
Keld

Re: [PATCH] Remove locale timezone information

[Paul Eggert]

On 08/06/2015 07:30 AM, keld@keldix.com wrote:
> Still, if you order the timezones for a country in some way, eg order of population,
> or alphabetically, you could probably find a solution that is useful to most
> people.

This is already done, by applications outside glibc.  For example, the 
tzselect program (part of of the tzcode distribution) lets you list 
tzdata names alphabetically, or in order of distance from your location, 
or geographically.  Other commonly-used time zone selectors do something 
fancier, e.g., based on <http://efele.net/maps/tz> shapefiles.  None of 
these selectors are based on the recently-removed glibc locale 
information, or would benefit from reverting the removal.

Re: [PATCH] Remove locale timezone information

[keld]

On Thu, Aug 06, 2015 at 07:47:01AM -0700, Paul Eggert wrote:
> On 08/06/2015 07:30 AM, keld@keldix.com wrote:
> >Still, if you order the timezones for a country in some way, eg order of 
> >population,
> >or alphabetically, you could probably find a solution that is useful to 
> >most
> >people.
> 
> This is already done, by applications outside glibc.  For example, the 
> tzselect program (part of of the tzcode distribution) lets you list 
> tzdata names alphabetically, or in order of distance from your location, 
> or geographically.  Other commonly-used time zone selectors do something 
> fancier, e.g., based on <http://efele.net/maps/tz> shapefiles.  None of 
> these selectors are based on the recently-removed glibc locale 
> information, or would benefit from reverting the removal.

Given that the data is not present in current locales, I understand this.
But with good data in the locales, that would be another matter.

best regards
keld

Re: [PATCH] Remove locale timezone information

[pinskia]

> On Aug 6, 2015, at 4:30 PM, keld@keldix.com wrote:
> 
>> On Wed, Aug 05, 2015 at 10:56:44PM -0400, Mike Frysinger wrote:
>>> On 05 Aug 2015 09:20, Paul Eggert wrote:
>>>> On 08/05/2015 03:22 AM, keld@keldix.com wrote:
>>>> For countries with more timezones, the locale data helps narrowing down the
>>>> choices. And there are not that many countries with more than 1 timezone,
>>>> eg USA, Canada, Russia and Greenland. Many big countries like China and India
>>>> only have 1 timezone
>>> 
>>> Actually, China has two time zones: tzdata's Asia/Shanghai and 
>>> Asia/Urumqi both reflect officially-kept time.  Even Germany has more 
>>> than one tzdata entry, due to the a difference in post-1970 history of 
>>> timekeeping in its Swiss enclaves.  So the problem of many time zones 
>>> for one locale is bigger than what you're suggesting, even if we ignore 
>>> traveling users (which is a pretty big class to ignore).
>> 
>> a cursory search shows many more countries as well:
>> Canada, USA, Mexico, Brazil, Australia, Russia, Mongolia, Kazakhstan,
>> Democratic Republic of Congo, Indonesia, Greenland (does that mean Denmark
>> too?).  that's at least 16% of the world's population (35% if you count
>> China).
> 
> I am glad you are now coming forward with actual facts, Mike.
> Then we can hopefully find out what the facts are, and probably agree on something.
> I have previously done discussion with people were we were intially 
> in violent diagreement, but along the road I got a little wiser and probably
> my opponent also got a little wiser, and we found some workable solutions. 
> That is why I keep responding to almost all of pour posts in a technical
> tone, and I hope you could do the same, for the benefit of the glibc project.
> 
> I have as you may know been involved with glibc i18n for many years,
> and I designed and speced many of the i18n enhancements over POSIX/C,
> and also provided lots of data for that purpose to the glibc project.
> If I am not corrected with my futurisic ideas, I will probably continue infinitely
> on this path - till now it has led us much of the way to where we are now.
> 
> Most of these countries I have already mentioned in previous posts.
> For Greenland, yes, it is part of the Kingdom of Denmark, but not part
> of the State of Denmark. Greenland has its own country code, and
> thus its own locales.
> 
> I also mentioned in previous posts that narrowing the choice of locales down to
> two or three is a big improvement over the current state, even if you cannot 
> fully determine a locale for a country. Do you think there is any merit in that
> observation, Mike?
> 
> My conclusion was then that the only countries that did not benefit 
> hugely on the narrow range of plausible locales were the USA, Canada and Russia.
> But anyway, having to chose between about a dozen different locales that can be presented 
> in one display, is a much nicer option than chosing amongst a long list of all glibc
> locales.
> 
>> and that's just for the current period of time.  as you highlight, if you
>> look back historically, there are other countries that spanned timezones.
> 
> Yes, the Olson tz database probably has all these data. 
> Still, if you order the timezones for a country in some way, eg order of population,
> or alphabetically, you could probably find a solution that is useful to most
> people. And then you have the option of setting a specific
> TZ variable if you have someting really special. This is UNIX, you know,
> we can tweek it endlessly.
> 
>> locales also are not strictly defined by country borders which means the
>> timezone spans are even higher (i'm not counting people who travel).
> 
> I doubt this is a big case. And anyway it can be tweeked, as noted above, right?

It is a big case in the gnu community and most open source community where people go to conferences. There is one such starting tomorrow. I doubt I want to force to use the one of the cet locals to get the timezone in Prague. 

Thanks,
Andrew


> 
> best regards
> Keld

Re: [PATCH] Remove locale timezone information

[keld]

On Thu, Aug 06, 2015 at 04:55:14PM +0200, pinskia@gmail.com wrote:
> 
> > On Aug 6, 2015, at 4:30 PM, keld@keldix.com wrote:
> > 
> > 
> >> locales also are not strictly defined by country borders which means the
> >> timezone spans are even higher (i'm not counting people who travel).
> > 
> > I doubt this is a big case. And anyway it can be tweeked, as noted above, right?
> 
> It is a big case in the gnu community and most open source community where people go to conferences. There is one such starting tomorrow. I doubt I want to force to use the one of the cet locals to get the timezone in Prague. 

I think we misunderstand eachother. I am in no doubt that people travel all the time,
and changing timezone is an issue here. I was not addressing that, but addressing that 
"locales also are not strictly defined by country borders which means the timezone spans are even higher".
I doubt that this is a big problem, but would like to hear where there are problems with this.

Travelling - I think this is a well known issue, and already solved. At least I travel a lot,
and I am happy that in my kde interface I can just click on the time displayed
in my bottom panel, and  change the time displayed to the one that I need.
Where do you foresee problems with the timezone category on this?
My take is that it does not change anything here.

Best regards
Keld

Re: [PATCH] Remove locale timezone information

[keld]

On Wed, Aug 05, 2015 at 09:20:14AM -0700, Paul Eggert wrote:
> On 08/05/2015 03:22 AM, keld@keldix.com wrote:
> >For countries with more timezones, the locale data helps narrowing down the
> >choices. And there are not that many countries with more than 1 timezone,
> >eg USA, Canada, Russia and Greenland. Many big countries like China and 
> >India
> >only have 1 timezone
> 
> Actually, China has two time zones: tzdata's Asia/Shanghai and 
> Asia/Urumqi both reflect officially-kept time.  Even Germany has more 
> than one tzdata entry, due to the a difference in post-1970 history of 
> timekeeping in its Swiss enclaves.  So the problem of many time zones 
> for one locale is bigger than what you're suggesting, even if we ignore 
> traveling users (which is a pretty big class to ignore).

It is always interesting with strange stories. Was there a differnce between German
an Swiss timezones? Something with Switzerland not being EU?
As written in earlier posts, you can always override standard TZ values in specific
cases. For travelling, I see no problem, at least I travel a lot, and I have
my local time changed easily. However all my timestamps are kept in UTC and in seconds
since the Epoch. Where do you see problems, Paul?

And my mother told me that "two" is not "many". Both your examples are for countries
with two timezones, and I guess that one of them are the one that the majority
will use. And then even for the minority, it will help them to just pick number two,
and not have to pick amongst myriads of timezones.

> As for tzdata names "not being culturally acceptable", they are intended 
> for use as internal identifiers, visible to experts like us but not to 
> end users, so "cultural acceptability" should not be an issue.  End 
> users in China, for example, are not expected to see "Asia/Shanghai" 
> even in an English locale, but instead are expected to see "China 
> Standard Time" or "Beijing Time" or something like that.  Strings like 
> "China Standard Time" and "????????????" are maintained by the Unicode 
> Common Locale Data Repository <http://cldr.unicode.org/> and are widely 
> used in glibc-based systems.  I don't know whether CLDR supports ISO TR 
> 14652 and 30112, but if it doesn't then I suggest approaching the CLDR 
> maintainers.

I take your word on timezone names, Paul, as I consider you close to the horse's mouth.
Good to know that the city names are only meant to be internal.
Still we need to convey that info to many developers on Linux install procedures, then.

CLDR was built with input from 14652, They killed it and tried to take over the info
of it and 15897. Embrace and  enhance. I will have a look on CLDR timezone names.

Best regards
Keld