* Removing locale timezone information @ 2015-06-03 15:57 Marko Myllynen 2015-06-03 21:33 ` Paul Eggert ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Marko Myllynen @ 2015-06-03 15:57 UTC (permalink / raw) To: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-06-03 15:57 Removing locale timezone information Marko Myllynen @ 2015-06-03 21:33 ` Paul Eggert 2015-06-03 21:33 ` keld 2015-06-12 14:05 ` [PATCH] Remove " Marko Myllynen 2 siblings, 0 replies; 47+ messages in thread From: Paul Eggert @ 2015-06-03 21:33 UTC (permalink / raw) To: myllynen, GNU C Library, libc-locales 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). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-06-03 15:57 Removing locale timezone information Marko Myllynen 2015-06-03 21:33 ` Paul Eggert @ 2015-06-03 21:33 ` keld 2015-06-05 8:28 ` Marko Myllynen 2015-06-12 14:05 ` [PATCH] Remove " Marko Myllynen 2 siblings, 1 reply; 47+ messages in thread From: keld @ 2015-06-03 21:33 UTC (permalink / raw) To: Marko Myllynen; +Cc: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-06-03 21:33 ` keld @ 2015-06-05 8:28 ` Marko Myllynen 2015-08-06 21:45 ` keld 0 siblings, 1 reply; 47+ messages in thread From: Marko Myllynen @ 2015-06-05 8:28 UTC (permalink / raw) To: keld; +Cc: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-06-05 8:28 ` Marko Myllynen @ 2015-08-06 21:45 ` keld 2015-08-06 21:45 ` pinskia ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: keld @ 2015-08-06 21:45 UTC (permalink / raw) To: Marko Myllynen; +Cc: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-06 21:45 ` keld @ 2015-08-06 21:45 ` pinskia 2015-08-06 21:46 ` keld 2015-08-07 2:33 ` Rich Felker 2015-08-07 0:45 ` Mike Frysinger 2015-08-07 21:49 ` Paul Eggert 2 siblings, 2 replies; 47+ messages in thread From: pinskia @ 2015-08-06 21:45 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales > 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-06 21:45 ` pinskia @ 2015-08-06 21:46 ` keld 2015-08-07 2:33 ` Rich Felker 1 sibling, 0 replies; 47+ messages in thread From: keld @ 2015-08-06 21:46 UTC (permalink / raw) To: pinskia; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-06 21:45 ` pinskia 2015-08-06 21:46 ` keld @ 2015-08-07 2:33 ` Rich Felker 1 sibling, 0 replies; 47+ messages in thread From: Rich Felker @ 2015-08-07 2:33 UTC (permalink / raw) To: pinskia; +Cc: keld, Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-06 21:45 ` keld 2015-08-06 21:45 ` pinskia @ 2015-08-07 0:45 ` Mike Frysinger 2015-08-09 21:12 ` keld 2015-08-07 21:49 ` Paul Eggert 2 siblings, 1 reply; 47+ messages in thread From: Mike Frysinger @ 2015-08-07 0:45 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-07 0:45 ` Mike Frysinger @ 2015-08-09 21:12 ` keld 0 siblings, 0 replies; 47+ messages in thread From: keld @ 2015-08-09 21:12 UTC (permalink / raw) To: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-06 21:45 ` keld 2015-08-06 21:45 ` pinskia 2015-08-07 0:45 ` Mike Frysinger @ 2015-08-07 21:49 ` Paul Eggert 2015-08-09 21:12 ` keld 2 siblings, 1 reply; 47+ messages in thread From: Paul Eggert @ 2015-08-07 21:49 UTC (permalink / raw) To: keld, Marko Myllynen; +Cc: GNU C Library, libc-locales 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-07 21:49 ` Paul Eggert @ 2015-08-09 21:12 ` keld 2015-08-09 21:12 ` Paul Eggert 0 siblings, 1 reply; 47+ messages in thread From: keld @ 2015-08-09 21:12 UTC (permalink / raw) To: Paul Eggert; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-09 21:12 ` keld @ 2015-08-09 21:12 ` Paul Eggert [not found] ` <20150812140837.GA23436@www5.open-std.org> 0 siblings, 1 reply; 47+ messages in thread From: Paul Eggert @ 2015-08-09 21:12 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales [-- 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <20150812140837.GA23436@www5.open-std.org>]
* Re: Removing locale timezone information [not found] ` <20150812140837.GA23436@www5.open-std.org> @ 2015-08-12 21:07 ` Zack Weinberg 2015-08-12 23:13 ` Keld Simonsen 2015-08-12 21:07 ` Paul Eggert ` (2 subsequent siblings) 3 siblings, 1 reply; 47+ messages in thread From: Zack Weinberg @ 2015-08-12 21:07 UTC (permalink / raw) To: Keld Simonsen; +Cc: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-12 21:07 ` Zack Weinberg @ 2015-08-12 23:13 ` Keld Simonsen 2015-08-12 23:13 ` Allan McRae 0 siblings, 1 reply; 47+ messages in thread From: Keld Simonsen @ 2015-08-12 23:13 UTC (permalink / raw) To: Zack Weinberg; +Cc: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information 2015-08-12 23:13 ` Keld Simonsen @ 2015-08-12 23:13 ` Allan McRae 0 siblings, 0 replies; 47+ messages in thread From: Allan McRae @ 2015-08-12 23:13 UTC (permalink / raw) To: Keld Simonsen, Zack Weinberg; +Cc: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information [not found] ` <20150812140837.GA23436@www5.open-std.org> 2015-08-12 21:07 ` Zack Weinberg @ 2015-08-12 21:07 ` Paul Eggert 2015-08-12 21:07 ` Andreas Schwab 2015-08-12 21:07 ` Allan McRae 3 siblings, 0 replies; 47+ messages in thread From: Paul Eggert @ 2015-08-12 21:07 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information [not found] ` <20150812140837.GA23436@www5.open-std.org> 2015-08-12 21:07 ` Zack Weinberg 2015-08-12 21:07 ` Paul Eggert @ 2015-08-12 21:07 ` Andreas Schwab 2015-08-12 21:07 ` Allan McRae 3 siblings, 0 replies; 47+ messages in thread From: Andreas Schwab @ 2015-08-12 21:07 UTC (permalink / raw) To: keld; +Cc: Paul Eggert, Marko Myllynen, GNU C Library, libc-locales 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." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: Removing locale timezone information [not found] ` <20150812140837.GA23436@www5.open-std.org> ` (2 preceding siblings ...) 2015-08-12 21:07 ` Andreas Schwab @ 2015-08-12 21:07 ` Allan McRae 3 siblings, 0 replies; 47+ messages in thread From: Allan McRae @ 2015-08-12 21:07 UTC (permalink / raw) To: keld, Paul Eggert; +Cc: Marko Myllynen, GNU C Library, libc-locales 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/ ^ permalink raw reply [flat|nested] 47+ messages in thread
* [PATCH] Remove locale timezone information @ 2015-06-12 14:05 ` Marko Myllynen 2015-08-05 9:07 ` Mike Frysinger 0 siblings, 1 reply; 47+ messages in thread From: Marko Myllynen @ 2015-06-12 14:05 UTC (permalink / raw) To: GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-06-12 14:05 ` [PATCH] Remove " Marko Myllynen @ 2015-08-05 9:07 ` Mike Frysinger 2015-08-05 11:51 ` keld 0 siblings, 1 reply; 47+ messages in thread From: Mike Frysinger @ 2015-08-05 9:07 UTC (permalink / raw) To: Marko Myllynen; +Cc: GNU C Library, libc-locales [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 9:07 ` Mike Frysinger @ 2015-08-05 11:51 ` keld 2015-08-05 11:51 ` keld 0 siblings, 1 reply; 47+ messages in thread From: keld @ 2015-08-05 11:51 UTC (permalink / raw) To: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:51 ` keld @ 2015-08-05 11:51 ` keld 2015-08-05 10:53 ` Mike Frysinger ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: keld @ 2015-08-05 11:51 UTC (permalink / raw) To: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:51 ` keld @ 2015-08-05 10:53 ` Mike Frysinger 2015-08-05 11:52 ` keld 2015-08-05 11:52 ` Andreas Schwab 2015-08-05 16:30 ` Paul Eggert 2 siblings, 1 reply; 47+ messages in thread From: Mike Frysinger @ 2015-08-05 10:53 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 10:53 ` Mike Frysinger @ 2015-08-05 11:52 ` keld 2015-08-05 12:39 ` Andreas Schwab 2015-08-05 13:33 ` Mike Frysinger 0 siblings, 2 replies; 47+ messages in thread From: keld @ 2015-08-05 11:52 UTC (permalink / raw) To: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:52 ` keld @ 2015-08-05 12:39 ` Andreas Schwab 2015-08-05 13:09 ` keld 2015-08-05 13:33 ` Mike Frysinger 1 sibling, 1 reply; 47+ messages in thread From: Andreas Schwab @ 2015-08-05 12:39 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales 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." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 12:39 ` Andreas Schwab @ 2015-08-05 13:09 ` keld 0 siblings, 0 replies; 47+ messages in thread From: keld @ 2015-08-05 13:09 UTC (permalink / raw) To: Andreas Schwab; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:52 ` keld 2015-08-05 12:39 ` Andreas Schwab @ 2015-08-05 13:33 ` Mike Frysinger 2015-08-05 15:56 ` Keld Simonsen 1 sibling, 1 reply; 47+ messages in thread From: Mike Frysinger @ 2015-08-05 13:33 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 13:33 ` Mike Frysinger @ 2015-08-05 15:56 ` Keld Simonsen 2015-08-05 16:30 ` Joseph Myers 2015-08-06 2:53 ` Mike Frysinger 0 siblings, 2 replies; 47+ messages in thread From: Keld Simonsen @ 2015-08-05 15:56 UTC (permalink / raw) To: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 15:56 ` Keld Simonsen @ 2015-08-05 16:30 ` Joseph Myers 2015-08-06 21:46 ` Keld Simonsen 2015-08-06 2:53 ` Mike Frysinger 1 sibling, 1 reply; 47+ messages in thread From: Joseph Myers @ 2015-08-05 16:30 UTC (permalink / raw) To: Keld Simonsen; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 16:30 ` Joseph Myers @ 2015-08-06 21:46 ` Keld Simonsen 2015-08-06 21:46 ` Joseph Myers 2015-08-06 21:46 ` Andreas Schwab 0 siblings, 2 replies; 47+ messages in thread From: Keld Simonsen @ 2015-08-06 21:46 UTC (permalink / raw) To: Joseph Myers; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 21:46 ` Keld Simonsen @ 2015-08-06 21:46 ` Joseph Myers 2015-08-06 21:46 ` Andreas Schwab 1 sibling, 0 replies; 47+ messages in thread From: Joseph Myers @ 2015-08-06 21:46 UTC (permalink / raw) To: Keld Simonsen; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 21:46 ` Keld Simonsen 2015-08-06 21:46 ` Joseph Myers @ 2015-08-06 21:46 ` Andreas Schwab 2015-08-06 21:46 ` Zack Weinberg 1 sibling, 1 reply; 47+ messages in thread From: Andreas Schwab @ 2015-08-06 21:46 UTC (permalink / raw) To: Keld Simonsen; +Cc: Joseph Myers, Marko Myllynen, GNU C Library, libc-locales 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." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 21:46 ` Andreas Schwab @ 2015-08-06 21:46 ` Zack Weinberg 0 siblings, 0 replies; 47+ messages in thread From: Zack Weinberg @ 2015-08-06 21:46 UTC (permalink / raw) To: Andreas Schwab Cc: Keld Simonsen, Joseph Myers, Marko Myllynen, GNU C Library, libc-locales 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." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 15:56 ` Keld Simonsen 2015-08-05 16:30 ` Joseph Myers @ 2015-08-06 2:53 ` Mike Frysinger 1 sibling, 0 replies; 47+ messages in thread From: Mike Frysinger @ 2015-08-06 2:53 UTC (permalink / raw) To: Keld Simonsen; +Cc: Marko Myllynen, GNU C Library, libc-locales [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:51 ` keld 2015-08-05 10:53 ` Mike Frysinger @ 2015-08-05 11:52 ` Andreas Schwab 2015-08-05 11:52 ` keld 2015-08-05 16:30 ` Paul Eggert 2 siblings, 1 reply; 47+ messages in thread From: Andreas Schwab @ 2015-08-05 11:52 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales 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." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:52 ` Andreas Schwab @ 2015-08-05 11:52 ` keld 2015-08-05 12:30 ` Andreas Schwab 0 siblings, 1 reply; 47+ messages in thread From: keld @ 2015-08-05 11:52 UTC (permalink / raw) To: Andreas Schwab; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:52 ` keld @ 2015-08-05 12:30 ` Andreas Schwab 2015-08-05 13:03 ` keld 0 siblings, 1 reply; 47+ messages in thread From: Andreas Schwab @ 2015-08-05 12:30 UTC (permalink / raw) To: keld; +Cc: Marko Myllynen, GNU C Library, libc-locales 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." ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 12:30 ` Andreas Schwab @ 2015-08-05 13:03 ` keld 0 siblings, 0 replies; 47+ messages in thread From: keld @ 2015-08-05 13:03 UTC (permalink / raw) To: Andreas Schwab; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 11:51 ` keld 2015-08-05 10:53 ` Mike Frysinger 2015-08-05 11:52 ` Andreas Schwab @ 2015-08-05 16:30 ` Paul Eggert 2015-08-06 2:56 ` Mike Frysinger 2015-08-06 17:14 ` keld 2 siblings, 2 replies; 47+ messages in thread From: Paul Eggert @ 2015-08-05 16:30 UTC (permalink / raw) To: keld, Marko Myllynen, GNU C Library, libc-locales 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 16:30 ` Paul Eggert @ 2015-08-06 2:56 ` Mike Frysinger 2015-08-06 17:13 ` keld 2015-08-06 17:14 ` keld 1 sibling, 1 reply; 47+ messages in thread From: Mike Frysinger @ 2015-08-06 2:56 UTC (permalink / raw) To: Paul Eggert; +Cc: keld, Marko Myllynen, GNU C Library, libc-locales [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 2:56 ` Mike Frysinger @ 2015-08-06 17:13 ` keld 2015-08-06 17:13 ` Paul Eggert 2015-08-06 17:14 ` pinskia 0 siblings, 2 replies; 47+ messages in thread From: keld @ 2015-08-06 17:13 UTC (permalink / raw) To: Paul Eggert, Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 17:13 ` keld @ 2015-08-06 17:13 ` Paul Eggert 2015-08-06 17:22 ` keld 2015-08-06 17:14 ` pinskia 1 sibling, 1 reply; 47+ messages in thread From: Paul Eggert @ 2015-08-06 17:13 UTC (permalink / raw) To: keld, Marko Myllynen, GNU C Library, libc-locales 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. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 17:13 ` Paul Eggert @ 2015-08-06 17:22 ` keld 0 siblings, 0 replies; 47+ messages in thread From: keld @ 2015-08-06 17:22 UTC (permalink / raw) To: Paul Eggert; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 17:13 ` keld 2015-08-06 17:13 ` Paul Eggert @ 2015-08-06 17:14 ` pinskia 2015-08-06 17:25 ` keld 1 sibling, 1 reply; 47+ messages in thread From: pinskia @ 2015-08-06 17:14 UTC (permalink / raw) To: keld; +Cc: Paul Eggert, Marko Myllynen, GNU C Library, libc-locales > 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-06 17:14 ` pinskia @ 2015-08-06 17:25 ` keld 0 siblings, 0 replies; 47+ messages in thread From: keld @ 2015-08-06 17:25 UTC (permalink / raw) To: pinskia; +Cc: Paul Eggert, Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [PATCH] Remove locale timezone information 2015-08-05 16:30 ` Paul Eggert 2015-08-06 2:56 ` Mike Frysinger @ 2015-08-06 17:14 ` keld 1 sibling, 0 replies; 47+ messages in thread From: keld @ 2015-08-06 17:14 UTC (permalink / raw) To: Paul Eggert; +Cc: Marko Myllynen, GNU C Library, libc-locales 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 ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2015-08-12 23:13 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-03 15:57 Removing locale timezone information Marko Myllynen 2015-06-03 21:33 ` Paul Eggert 2015-06-03 21:33 ` keld 2015-06-05 8:28 ` Marko Myllynen 2015-08-06 21:45 ` keld 2015-08-06 21:45 ` pinskia 2015-08-06 21:46 ` keld 2015-08-07 2:33 ` Rich Felker 2015-08-07 0:45 ` Mike Frysinger 2015-08-09 21:12 ` keld 2015-08-07 21:49 ` Paul Eggert 2015-08-09 21:12 ` keld 2015-08-09 21:12 ` Paul Eggert [not found] ` <20150812140837.GA23436@www5.open-std.org> 2015-08-12 21:07 ` Zack Weinberg 2015-08-12 23:13 ` Keld Simonsen 2015-08-12 23:13 ` Allan McRae 2015-08-12 21:07 ` Paul Eggert 2015-08-12 21:07 ` Andreas Schwab 2015-08-12 21:07 ` Allan McRae 2015-06-12 14:05 ` [PATCH] Remove " Marko Myllynen 2015-08-05 9:07 ` Mike Frysinger 2015-08-05 11:51 ` keld 2015-08-05 11:51 ` keld 2015-08-05 10:53 ` Mike Frysinger 2015-08-05 11:52 ` keld 2015-08-05 12:39 ` Andreas Schwab 2015-08-05 13:09 ` keld 2015-08-05 13:33 ` Mike Frysinger 2015-08-05 15:56 ` Keld Simonsen 2015-08-05 16:30 ` Joseph Myers 2015-08-06 21:46 ` Keld Simonsen 2015-08-06 21:46 ` Joseph Myers 2015-08-06 21:46 ` Andreas Schwab 2015-08-06 21:46 ` Zack Weinberg 2015-08-06 2:53 ` Mike Frysinger 2015-08-05 11:52 ` Andreas Schwab 2015-08-05 11:52 ` keld 2015-08-05 12:30 ` Andreas Schwab 2015-08-05 13:03 ` keld 2015-08-05 16:30 ` Paul Eggert 2015-08-06 2:56 ` Mike Frysinger 2015-08-06 17:13 ` keld 2015-08-06 17:13 ` Paul Eggert 2015-08-06 17:22 ` keld 2015-08-06 17:14 ` pinskia 2015-08-06 17:25 ` keld 2015-08-06 17:14 ` keld
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).