[PATCH 0/1] Add Asia/Beijing
I know this is a controversial topic, but I've been asked to submit this, and have decided to do so for a few reasons: * We'll stop getting questions of why Beijing Time is not included. * People that want to ship their own modified version of tzdata can take this patch. * The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this, leading to continued confusion from users. * I've seen it argued that we have to keep the the database pristine, yet the bar for entry does not actually seem that high. For example, we have a link from the Vatican to Rome, even though it should be pretty obvious that they're the same time zone. And we have a Link for people that can't seem to figure out if Nicosia is in Europe or Asia. * This really does seem to confuse users. "Eastern Time" includes both Washington, D.C. and New York City. The justification is that we never added Washington to the list, so we shouldn't add Beijing. But this is really not a fair comparison. It's called "Beijing Time". I'm sure if ET was called "Washington Time", it would at least give me pause to select New York time, even though I'm a New Yorker. No one gets confused that they have to pick New York, or Madrid instead of Barcelona, so that argument doesn't hold water.
This adds Asia/Beijing to the zone.tab file, as an alias to Shanghai timezone. This is necessary because it's confusing to Chinese users, who use the name "Beijing Time", and sometimes "Chinese Standard Time", but never "Shanghai Time". Signed-off-by: James M Leddy <james.leddy@canonical.com> --- asia | 2 ++ zone.tab | 1 + 2 files changed, 3 insertions(+) diff --git a/asia b/asia index a02e109..ae3cd55 100644 --- a/asia +++ b/asia @@ -387,6 +387,8 @@ Zone Asia/Harbin 8:26:44 - LMT 1928 # or Haerbin Zone Asia/Shanghai 8:05:52 - LMT 1928 8:00 Shang C%sT 1949 8:00 PRC C%sT +# Native Chinese users prefer this be called Beijing time +Link Asia/Shanghai Asia/Beijing # Long-shu Time (probably due to Long and Shu being two names of that area) # Guangxi, Guizhou, Hainan, Ningxia, Sichuan, Shaanxi, and Yunnan; # most of Gansu; west Inner Mongolia; west Qinghai; and the Guangdong diff --git a/zone.tab b/zone.tab index 6bda826..87ada17 100644 --- a/zone.tab +++ b/zone.tab @@ -146,6 +146,7 @@ CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago most locations CL -2709-10926 Pacific/Easter Easter Island & Sala y Gomez CM +0403+00942 Africa/Douala +CN +3954+11625 Asia/Beijing alias to Asia/Shanghai CN +3114+12128 Asia/Shanghai east China - Beijing, Guangdong, Shanghai, etc. CN +4545+12641 Asia/Harbin Heilongjiang (except Mohe), Jilin CN +2934+10635 Asia/Chongqing central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc. -- 1.7.9.5
On Aug 13, 2012, at 3:49 PM, James M Leddy wrote:
I know this is a controversial topic, but I've been asked to submit this, and have decided to do so for a few reasons:
* We'll stop getting questions of why Beijing Time is not included.
* People that want to ship their own modified version of tzdata can take this patch.
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this, leading to continued confusion from users.
* I've seen it argued that we have to keep the the database pristine, yet the bar for entry does not actually seem that high. For example, we have a link from the Vatican to Rome, even though it should be pretty obvious that they're the same time zone. And we have a Link for people that can't seem to figure out if Nicosia is in Europe or Asia.
* This really does seem to confuse users. "Eastern Time" includes both Washington, D.C. and New York City. The justification is that we never added Washington to the list, so we shouldn't add Beijing. But this is really not a fair comparison. It's called "Beijing Time". I'm sure if ET was called "Washington Time", it would at least give me pause to select New York time, even though I'm a New Yorker. No one gets confused that they have to pick New York, or Madrid instead of Barcelona, so that argument doesn't hold water.
So if we adopt this, how many thousand additional patches like this will we have to adopt as well? paul
On 08/13/2012 04:00 PM, Paul_Koning@Dell.com wrote:
On Aug 13, 2012, at 3:49 PM, James M Leddy wrote:
I know this is a controversial topic, but I've been asked to submit this, and have decided to do so for a few reasons:
* We'll stop getting questions of why Beijing Time is not included.
* People that want to ship their own modified version of tzdata can take this patch.
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this, leading to continued confusion from users.
* I've seen it argued that we have to keep the the database pristine, yet the bar for entry does not actually seem that high. For example, we have a link from the Vatican to Rome, even though it should be pretty obvious that they're the same time zone. And we have a Link for people that can't seem to figure out if Nicosia is in Europe or Asia.
* This really does seem to confuse users. "Eastern Time" includes both Washington, D.C. and New York City. The justification is that we never added Washington to the list, so we shouldn't add Beijing. But this is really not a fair comparison. It's called "Beijing Time". I'm sure if ET was called "Washington Time", it would at least give me pause to select New York time, even though I'm a New Yorker. No one gets confused that they have to pick New York, or Madrid instead of Barcelona, so that argument doesn't hold water.
So if we adopt this, how many thousand additional patches like this will we have to adopt as well?
Little to none, as far as I can tell. The criteria are: * The timezone is named after a city, one that's already not in zone.tab * The naming confuses users, to the point that they keep trying to click on the map closer to Beijing to get the timezone, and repeatedly bring it up on mailing-lists/bugzillas. * The change affects 1.3 billion people [possibly not a valid criterion] It's interesting that you were the first to respond, because Dell is one of the OEM's requesting us to change it :)
On 8/13/2012 1:00 PM, Paul_Koning@Dell.com wrote:
On Aug 13, 2012, at 3:49 PM, James M Leddy wrote:
I know this is a controversial topic, but I've been asked to submit this, and have decided to do so for a few reasons:
So if we adopt this, how many thousand additional patches like this will we have to adopt as well?
I felt this question deserved an answer, so I compared Wikipedia's list of countries whose largest city is not their Capital with the TZ database. (Presuming that if a country's largest city is their capital, that's the city name we are using in the TZ database) Here are the results: * There are 37 countries where the largest city is not also the country's capital. * Of those, 26 have a zone identified by their largest city, 5 are identified by their capital, 4 are identified by the name of the country, 1 is identified by the name of the 7th largest city, 1 uses the name of the state/island, and one lists both the largest city and the capital. * Looking at all 37 countries, there are 23 where the largest city is more than twice the size of the capital. In all of those instances, a Zone Identifier currently used is either the name of the largest city or the name of the country itself. I don't see a need to change or link any of these. * Of the remaining 14 countries, 5 zones use names that clearly need no changes due to the nature of the current zone name or the conurbation of the capital and largest city: - Country, Capital, largest city, Current TZ Name - Republic of China (Taiwan), Taipei, New Taipei, Taipei - Micronesia, Palikir, Weno, Chuuk/Yap (State/Island-Named Zone) - Sudan, Khartoum, 2,207,794, Omdurman, 2,395,159, Khartoum (Omdurman is across the river from Khartoum and can be considered part of the Khartoum metropolitan area) - Liechtenstein, Vaduz, 5,109, Schaan, 5,806, Vaduz (Schaan is adjacent to Vaduz, and can be considered as part of the Vaduz metropolitan area) - Trinidad and Tobago, Port of Spain, 49,000, Chaguanas, 67,400, Port of Spain (Chaguanas is adjacent to Port of Spain, and can be considered as part of the Port of Spain metropolitan area) * That leaves 9 countries for which we could make a reasonable case for adding a link in the TZ database if we did so for China. Here they are: - Country, Capital, Population, Largest City, Population, Current Zone - China, Beijing, 22,000,000, Shanghai, 23,210,000, Shanghai - Vietnam, Hanoi, 6,500,00, Ho Chi Minh City (Saigon), 7,123,340, Ho Chi Minh City (Saigon) - India, Delhi, 11,007,835, Mumbai, 13,830,884, Kolkata/Calcutta (!) - Syria, Damascus, 1,711,000, Aleppo, 2,301,570, Damascus - Cameroon, Yaounde, 1,430,000, Douala, 2,000,000, Douala - Malawi, Lilongwe, 781,538, Blantyre, 728,285, Blantyre - South Africa, Pretoria, 2,345,908, Johannesburg, 3,888,180, Johannesburg - Equador, Quito, 1,397,698, Guayaquil, 2,600,000, Guayaquil - Kazakhstan, Astana, 743,014, Almaty, 1,450,095, Almaty Based on the above, the maximum number of patches we would need to make today is 37, and it's possible to craft a guideline like the one above that would result in 9 patches today and relatively few additional patches going forward. I've posted the master spreadsheet containing data on all 37 countries here: https://docs.google.com/spreadsheet/ccc?key=0Aqfda0tRjlb_dHMtTXBET2xRWFlZY0o... I hope this information is useful and enhances the quality of the debate on this never-ending issue. --Ted
Thanks for the research and spreadsheet. It is very useful. Being Canadian, I am intruiged by Ottawa, which is the capital of Canada, the second largest city in Ontario, and the fourth largest in Canada. It seems that since 1970, Ottawa and Toronto and Montreal have followed the same timezone/saylight saving rules, but prior to that, Ottawa and environs was likely more in sync with Montreal's daylight saving rules than Toronto's rules for proximity and commercial reasons. As well, Montreal, not Toronto, was the largest city in Canada until about 1975. So, as far as I understand the rules, Ottawa does not require a link in tz at this time - but if a link for capitals is ever added in tz - the preferred link for Ottawa should probably be Montreal, not Toronto.
I don't think any of the extra links are useful or necessary, and are just complications for no good purpose. As noted in other messages: 1. The TZ identifiers are simply internal identifiers. Any good UI will map to them, but have a very different presentation (including translation). The fewer the better, and the fewer gratuitous changes (like spelling) the better. 2. UIs that present cities are going to have many more cities, enough that people can pick one that they know about without having to be aware that they are all in the same zone. (If I'm a German on a trip to Vegas, I'm going to want to pick Vegas for the timezone rather than having to know that Vegas is in the same zone as Los Angeles and not Denver or Phoenix.) Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Wed, Aug 15, 2012 at 5:33 AM, David Patte ₯ <dpatte@relativedata.com>wrote:
Thanks for the research and spreadsheet. It is very useful.
Being Canadian, I am intruiged by Ottawa, which is the capital of Canada, the second largest city in Ontario, and the fourth largest in Canada. It seems that since 1970, Ottawa and Toronto and Montreal have followed the same timezone/saylight saving rules, but prior to that, Ottawa and environs was likely more in sync with Montreal's daylight saving rules than Toronto's rules for proximity and commercial reasons. As well, Montreal, not Toronto, was the largest city in Canada until about 1975.
So, as far as I understand the rules, Ottawa does not require a link in tz at this time - but if a link for capitals is ever added in tz - the preferred link for Ottawa should probably be Montreal, not Toronto.
Mark Davis ␦ <mark@macchiato.com> wrote: |I don't think any of the extra links are useful or necessary, and are just |complications for no good purpose. As noted in other messages: | | 1. The TZ identifiers are simply internal identifiers. Any good UI will | map to them, but have a very different presentation (including | translation). The fewer the better, and the fewer gratuitous changes (like | spelling) the better. Except for Mac OS X all operating systems i use simply map Olson's hierarchy. I don't think i need to look at the installation stuff to say that, but i may be mistaken, so please correct me if that is the case. And i don't think always-on needs-a-webservice-to-run is a good thing either, not at least for many many people who maybe don't have an internet connection at all (by themselves, for free, or whatever). The first part is surely my opinion and nothing else. If it's so easy to improve the experience for so many people, and given all those aliases that yet exist, and maybe the circumstance that Bejing is rather official, and that Bejing is the place where the emperor had it's palace, in short, then i would include the name Bejing in a DB. (In fact i think i would even add a text file with some more mappings, maybe even containing GPS/Galileo coordinates, and let it grow over time. I.e., 'TZ COUNTRY [STATE] CITY COORDINATES' or whatever. How large would it get? Anyway, with it, the Olson Database would almost be self-contained. But i'm not a real expert, i'm a programmer which use[sd] it in it's own products. Thanks.) | 2. UIs that present cities are going to have many more cities, enough | that people can pick one that they know about without having to be aware | that they are all in the same zone. (If I'm a German on a trip to Vegas, | I'm going to want to pick Vegas for the timezone rather than having to know | that Vegas is in the same zone as Los Angeles and not Denver or Phoenix.) As two site notes: if a german drives to Vegas, he and she are most likely about to go for a fast and/or big wedding (even though i think divorce rules have changed in Germany for such marriages, but i'm very undecided wether my memory is correct here). So let's just hope for them that all they look for is "is it dark outside?", horray. (Horray!!) |Mark <https://plus.google.com/114199149796022210033> |* |* |*— Il meglio è l’inimico del bene —* |** --steffen
I would like to mention another consideration. The tzdata database is used in embedded systems, not just workstations/servers with lots of memory and disk space. For that usage, it needs to be complete. But having lots of extra references to a given set of zone rules, to satisfy user interface polishing requirements, is a problem for memory-limited systems. Could we please move UI improvements out of the TZ project? paul
Paul_Koning@Dell.com <Paul_Koning@Dell.com> wrote on Wed, 15 Aug 2012 at 16:12:44 +0000 in <C75A84166056C94F84D238A44AF9F6AD190662@AUSX10MPC102.AMER.DELL.COM>:
The tzdata database is used in embedded systems, not just workstations/servers with lots of memory and disk space. For that usage, it needs to be complete. But having lots of extra references to a given set of zone rules, to satisfy user interface polishing requirements, is a problem for memory-limited systems.
This just doesn't ring true to me. If the amount of space take up by 100 more aliases (much less 37, or 9) is significant, then something is very very wrong.
Could we please move UI improvements out of the TZ project?
There's just not clear concensus that we should. The reality is that, despite what implementors allegedly *should* do, users frequently do encounter tz identifiers. This is manifestly true, otherwise we would not hear so many complaints about it. Personally, I suppose I'm a baroque elitist because I try to answer questions like, "What time is it in Hong Kong?" by typing $ TZ=Asia/Hong_Kong date Thu Aug 16 00:20:34 HKT 2012 Because I don't have some superior tool that answers the question for me. And it seems like no amount of zone.tab improvements or installation-time picker improvements are going to improve that situation for me. As I wrote offline to Paul, it seems clear to me that the amount of time wasted in the past decade by repeating this conversation on the list grossly outweights the time to actually make the change. We should make the change, adjust our rules, and carry onward. And if it turns out to be a bad idea, well, we can change our minds again. At least we'll have dealt with the most populous cases so they won't keep coming up again. Digging in our heels just isn't making anyone happy. --jhawk@mit.edu John Hawkinson
On Aug 15, 2012, at 12:23 PM, John Hawkinson wrote:
Paul_Koning@Dell.com <Paul_Koning@Dell.com> wrote on Wed, 15 Aug 2012 at 16:12:44 +0000 in <C75A84166056C94F84D238A44AF9F6AD190662@AUSX10MPC102.AMER.DELL.COM>:
The tzdata database is used in embedded systems, not just workstations/servers with lots of memory and disk space. For that usage, it needs to be complete. But having lots of extra references to a given set of zone rules, to satisfy user interface polishing requirements, is a problem for memory-limited systems.
This just doesn't ring true to me. If the amount of space take up by 100 more aliases (much less 37, or 9) is significant, then something is very very wrong.
That's your opinion, and you're welcome to it. The issue is that it isn't just capitals. You mentioned those and some other people mentioned them, but others have discussed this as a generic wish to be able to point to some spot on a map, or mention the town they are in, and have the right timezone pop up. That's a perfectly valid wish but it's a UI matter, and it belongs in systems that have the space for such databases. paul
Paul_Koning@Dell.com said:
The tzdata database is used in embedded systems, not just workstations/servers with lots of memory and disk space. For that usage, it needs to be complete. But having lots of extra references to a given set of zone rules, to satisfy user interface polishing requirements, is a problem for memory-limited systems. This just doesn't ring true to me. If the amount of space take up by 100 more aliases (much less 37, or 9) is significant, then something is very very wrong. That's your opinion, and you're welcome to it.
I work on embedded systems. We are always on the edge and every single byte saved is worth it. 9 names of 12 bytes each is over 100 bytes, which is far too much memory to just throw away without good reason. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 08/15/2012 12:23 PM, John Hawkinson wrote:
Could we please move UI improvements out of the TZ project? There's just not clear concensus that we should.
The reality is that, despite what implementors allegedly *should* do, users frequently do encounter tz identifiers. This is manifestly true, otherwise we would not hear so many complaints about it.
I completely agree. For 99% of timezones, we have a link that works, and that can be presented to the user in time zone picker apps (even if it's not supposed to). This breaks* for one timezone, and it just so happens that that timezone is probably the most populous in the entire database. My motivation is a little selfish in that this one line change will make any changes to time zone picker apps unnecessary. But by not taking that we're necessitating many man-hours of work for UI changes for all the apps that currently use zone.tab. I agree, zone.tab is _not_ good for presenting human-readable names, but the truth is, it's also not _bad_. * Where "breaks" in this case means that the timezone as used in casual speech is named after a city, one that's not in the zone.tab already, and users are so confused with the name of their zone in zone.tab that they actually think it's wrong and their timezone is just missing.
<Paul_Koning@Dell.com> wrote: |I would like to mention another consideration. | |The tzdata database is used in embedded systems, not just workstations/servers with lots of memory and disk space. For that usage, it needs to be complete. But having lots of extra references to a given set of zone rules, to satisfy user interface polishing requirements, is a problem for memory-limited systems. On the other hand, now that Paul Eggert has switched to git(1), selective branches would be possible, automatically setup from a worker branch. Or multiple make(1) rules. Or multiple zone.tabs with several levels of detail, for more specific addressing and/or converting "comments" into easy translatable entities or atoms which then can be used directly for other purposes, like geoname lookup, or whatever, maybe setup via a script, as above, to choose the level of detail. zone.tab was 19913 bytes for (Release tzcode2012e and tzdata2012e., 2012-08-02), that is not much for entire planet earth, so to say. |Could we please move UI improvements out of the TZ project? You're welcome. | paul --steffen
<<On Wed, 15 Aug 2012 17:52:25 +0200, sdaoden@gmail.com (Steffen "Daode" Nurpmeso) said:
Except for Mac OS X all operating systems i use simply map Olson's hierarchy.
Then they're doing it wrong. Does anyone remember when zone.tab was added to the distribution? I wrote an application to use it more than ten years ago. FreeBSD users have long been asked to select among: east China - Beijing, Guangdong, Shanghai, etc. Heilongjiang (except Mohe), Jilin central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc. most of Tibet & Xinjiang west Tibet & Xinjiang We don't present the TZids at all. Users are welcome to learn about them, and they have some utility for command-line use with date(1), but they truly are an implementation detail. -GAWollman
On 08/15/2012 12:22 PM, Garrett Wollman wrote:
<<On Wed, 15 Aug 2012 17:52:25 +0200, sdaoden@gmail.com (Steffen "Daode" Nurpmeso) said:
Except for Mac OS X all operating systems i use simply map Olson's hierarchy.
Then they're doing it wrong.
Does anyone remember when zone.tab was added to the distribution? I wrote an application to use it more than ten years ago. FreeBSD users have long been asked to select among:
east China - Beijing, Guangdong, Shanghai, etc. Heilongjiang (except Mohe), Jilin central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc. most of Tibet & Xinjiang west Tibet & Xinjiang
Then we have gems like: KZ +4315+07657 Asia/Almaty most locations I'm all for better comment fields, but since most of the timezones don't have comments this work will take a while.
On 8/15/2012 3:16 PM, James M Leddy wrote:
On 08/15/2012 12:22 PM, Garrett Wollman wrote:
FreeBSD users have long been asked to select among:
east China - Beijing, Guangdong, Shanghai, etc. Heilongjiang (except Mohe), Jilin central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc. most of Tibet & Xinjiang west Tibet & Xinjiang Then we have gems like:
KZ +4315+07657 Asia/Almaty most locations Such a line is supposed to be presented as something like "Kazakhstan: most locations", which is fine, not just "most locations" alone (and I suspect the example FreeBSD menu above is all under a submenu labeled China) - the country code is part of what's intended to be shown to the user.
Garrett Wollman <wollman@csail.mit.edu> wrote: |<<On Wed, 15 Aug 2012 17:52:25 +0200, sdaoden@gmail.com (Steffen "Daode" Nurpmeso) said: | |> Except for Mac OS X all operating systems i use simply map Olson's |> hierarchy. | |Then they're doing it wrong. | |Does anyone remember when zone.tab was added to the distribution? I |wrote an application to use it more than ten years ago. FreeBSD users |have long been asked to select among: | | east China - Beijing, Guangdong, Shanghai, etc. | Heilongjiang (except Mohe), Jilin | central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc. | most of Tibet & Xinjiang | west Tibet & Xinjiang | |We don't present the TZids at all. Users are welcome to learn about |them, and they have some utility for command-line use with date(1), |but they truly are an implementation detail. | |-GAWollman Indeed. Though it seems to me that "more than ten years ago" is a nice euphemism for 1996-11-19 18:09:41 +0000. :). Aaaah, the cosy comfort after doing [Shell] -> mount -> newfs -> tar -x -f PACKAGES to not run into the inode limits the default installer produces.. --steffen
On Wed, 15 Aug 2012, David Patte ₯ wrote:
Thanks for the research and spreadsheet. It is very useful.
Being Canadian, I am intruiged by Ottawa, which is the capital of Canada, the second largest city in Ontario, and the fourth largest in Canada. It seems that since 1970, Ottawa and Toronto and Montreal have followed the same timezone/saylight saving rules, but prior to that, Ottawa and environs was likely more in sync with Montreal's daylight saving rules than Toronto's rules for proximity and commercial reasons. As well, Montreal, not Toronto, was the largest city in Canada until about 1975.
So, as far as I understand the rules, Ottawa does not require a link in tz at this time - but if a link for capitals is ever added in tz - the preferred link for Ottawa should probably be Montreal, not Toronto.
This IMO partly illustrates why we should not make any links. The idea is that TZ identifiers are unique and *stable*. In the list, there are plenty of IDs with as comment "Used to be the capital until 19xx". In the case of Ottawa and Montreal, if you add a link, and then Quebec decides to split off Canada and choses to use Europe/Paris (which is not that far sought ;-) ) then you end up having a non-stable ID as Ottawa and Montreal no longer can be linked. The issue of Beijing/Shanghai has been discussed many times, and I feel that we shouldn't revisit it anymore. TZIDs are not meant to be used in userland - this is document. Unicode's CLDR (http://unicode.org/repos/cldr-tmp/trunk/diff/summary/de.html, search for "AT/Vienna", "Europe/London" f.e., as well as http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html) already provide user-visable names for many languages and timezones - and this would be the perfect place for all sorts of display rules. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug
On 08/14/2012 03:49 AM, James M Leddy wrote:
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this
I happened to read this on my laptop which runs Ubuntu 12.04 and uses the tz database. I clicked on the time in the upper right-hand part of my screen, clicked on "Time & Date Settings", typed "Beijing", and it automatically changed my desktop to Beijing Time aka CST. So, not only has it been done, it's been done on a platform that your company helps maintain....
* we have a link from the Vatican to Rome, even though it should be pretty obvious that they're the same time zone.
In hindsight perhaps we should not have had a separate entry for each country, as this has resulted in all sorts of nationalistic commentary that has little to do with the actual data. I'd rather not make matters worse, though.
It's called "Beijing Time".
And time in London is called "Greenwich Mean Time". But we do not have a Europe/Greenwich entry.
On 08/13/2012 04:12 PM, Paul Eggert wrote:
On 08/14/2012 03:49 AM, James M Leddy wrote:
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this
I happened to read this on my laptop which runs Ubuntu 12.04 and uses the tz database. I clicked on the time in the upper right-hand part of my screen, clicked on "Time & Date Settings", typed "Beijing", and it automatically changed my desktop to Beijing Time aka CST.
So, not only has it been done, it's been done on a platform that your company helps maintain....
True, but it's not exactly the same thing. The first problem is that you lose this if you don't have Internet connectivity, and on first install a lot of people expect to install from the CD without Internet. Then there's the problem that even though you pick Beijing, you still get the tack on Shanghai. It's hard to tell in China, but pick Miami, FL or something and you'll see it's still in New York. And we had to hack around to save the input city so that it comes back correctly. Also if you click on the map without using the input box, you still get the old functionality. I'm talking with the indicator-datetime developers to see if we can include the geonames database on the install medium, but they asked me to submit here first. Ubuntu Unity and MeeGo are the only distros that I know of that have done anything about this, and our solution isn't even that great. Fedora users, KDE users etc. are still out of luck. More info in bug 892370 : https://bugs.launchpad.net/bugs/892370
* we have a link from the Vatican to Rome, even though it should be pretty obvious that they're the same time zone.
In hindsight perhaps we should not have had a separate entry for each country, as this has resulted in all sorts of nationalistic commentary that has little to do with the actual data. I'd rather not make matters worse, though.
It's called "Beijing Time".
And time in London is called "Greenwich Mean Time". But we do not have a Europe/Greenwich entry.
Fair point. Though I think my overall point about Greenwich residents not being as confused as Beijing residents or even Shanghai residents stands though.
On Aug 13, 2012, at 1:39 PM, James M Leddy wrote:
Then there's the problem that even though you pick Beijing, you still get the tack on Shanghai. It's hard to tell in China, but pick Miami, FL or something and you'll see it's still in New York.
That's a bug. In OS X's System Preferences, I can drag the blue dot to Miami and it stays there, even though it's set /etc/localtime to link to America/New_York.
I'm talking with the indicator-datetime developers to see if we can include the geonames database on the install medium,
Is that a technical issue or a licensing issue?
On 08/13/2012 04:50 PM, Guy Harris wrote:
On Aug 13, 2012, at 1:39 PM, James M Leddy wrote:
Then there's the problem that even though you pick Beijing, you still get the tack on Shanghai. It's hard to tell in China, but pick Miami, FL or something and you'll see it's still in New York.
That's a bug. In OS X's System Preferences, I can drag the blue dot to Miami and it stays there, even though it's set /etc/localtime to link to America/New_York.
Interesting, I had no idea OS X was using geonames as well and just assumed everyone was talking about Ubuntu Unity.
I'm talking with the indicator-datetime developers to see if we can include the geonames database on the install medium,
Is that a technical issue or a licensing issue?
Purely technical, I expect we'll go that route (or another route) if we can't change the timezone database, but it'll cost developer time and won't benefit any of the other distros/DEs.
On Aug 13, 2012, at 1:54 PM, James M Leddy wrote:
Interesting, I had no idea OS X was using geonames as well and just assumed everyone was talking about Ubuntu Unity.
Bad assumption. If nothing else, it'll probably annoy the Fedora users, KDE users, and GNOME users. :-)
Purely technical, I expect we'll go that route (or another route) if we can't change the timezone database, but it'll cost developer time and won't benefit any of the other distros/DEs.
If it's a question of code being written to use the database, it won't benefit any of the other distributions/DEs only if 1) you don't give the code away or 2) you do and nobody else picks it up. For the first of them, if your interest is in the open-source environments, giving it away would be a Good Thing. For the second of them, well, that's *their* loss, especially if there are some upstream "date and time" configuration panels that they can all just pick up.
On 08/13/2012 04:59 PM, Guy Harris wrote:
On Aug 13, 2012, at 1:54 PM, James M Leddy wrote:
Interesting, I had no idea OS X was using geonames as well and just assumed everyone was talking about Ubuntu Unity.
Bad assumption. If nothing else, it'll probably annoy the Fedora users, KDE users, and GNOME users. :-)
Purely technical, I expect we'll go that route (or another route) if we can't change the timezone database, but it'll cost developer time and won't benefit any of the other distros/DEs.
If it's a question of code being written to use the database, it won't benefit any of the other distributions/DEs only if
1) you don't give the code away
or
2) you do and nobody else picks it up.
For the first of them, if your interest is in the open-source environments, giving it away would be a Good Thing. For the second of them, well, that's *their* loss, especially if there are some upstream "date and time" configuration panels that they can all just pick up.
You forgot 3) No one picks it up but they gripe that we forked indicator-datetime in the first place. In all honesty I'd port the patch to gnome time picker to avoid that.
On Mon, Aug 13, 2012 at 1:12 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/14/2012 03:49 AM, James M Leddy wrote:
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this
I happened to read this on my laptop which runs Ubuntu 12.04 and uses the tz database. I clicked on the time in the upper right-hand part of my screen, clicked on "Time & Date Settings", typed "Beijing", and it automatically changed my desktop to Beijing Time aka CST.
For whatever it is worth, on Mac OS X (10.7.4), the System Preferences Time & Date panel allows you to choose the time zone by clicking on a world map. Clicking on one place in China came up with a name like 'Yueying - China' , so I typed 'Beijing - China' and that was accepted (and the highlighted location moved nearer to where Beijing actually is). So, Apple has done this job on Mac OS X, I think. That's not a definitive for or against the addition — it is just a data point for consideration. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On 13/08/12 21:12, Paul Eggert wrote:
It's called "Beijing Time". And time in London is called "Greenwich Mean Time". But we do not have a Europe/Greenwich entry.
It's called Greenwich Mean Time in the *winter* months. Right now we're on British Summer Time and there isn't a Europe/British either :) jch
|I happened to read this on my laptop which runs Ubuntu 12.04 and uses |the tz database. I clicked on the time in the upper right-hand part |of my screen, clicked on "Time & Date Settings", typed "Beijing", and |it automatically changed my desktop to Beijing Time aka CST. Once USB Plug&Play was presented first a blue screen was seen. The earth's surface consists of a lot of water and many deserts, both of which are growing, if seen from the outside. --steffen
On Aug 13, 2012, at 12:49 PM, James M Leddy wrote:
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this,
The desktop (well, laptop) Un*x[*] I'm running will, if I open System Preferences, disable "Set time zone automatically using current location", and drag the little blue location dot over towards China, offer a Time Zone of "China Standard Time" and list a number of cities in the drop-down list, including "Beijing - China" - and symlinks /etc/localtime to /usr/share/zoneinfo/Asia/Harbin. The map it displays has "Geonames.org" on it. http://www.geonames.org says "The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge."; it's licensed under a Creative Commons Attribution 3.0 License. According to http://www.geonames.org/export/web-services.html one service they offer is "Timezone":
Timezone
Webservice Type : REST Url : api.geonames.org/timezone? Parameters : lat,lng, radius (buffer in km for closest timezone in coastal areas), date (date for sunrise/sunset); Result : the timezone at the lat/lng with gmt offset (1. January) and dst offset (1. July) Example http://api.geonames.org/timezone?lat=47.01&lng=10.2&username=demo
This service is also available in JSON format : http://api.geonames.org/timezoneJSON?lat=47.01&lng=10.2&username=demo
Element: timezoneId: name of the timezone (according to olson), this information is sufficient to work with the timezone and defines DST rules, consult the documentation of your development environment. time: the local current time rawOffset: the amount of time in hours to add to UTC to get standard time in this time zone. Because this value is not affected by daylight saving time, it is called raw offset. gmtOffset: offset to GMT at 1. January (deprecated) dstOffset: offset to GMT at 1. July (deprecated)
so it appears that it translates a location to, among other things, an Olson database name. The example URL is for some location in Austria, as the XML that comes back is
<geonames> <timezone tzversion="tzdata2012c"> <countryCode>AT</countryCode> <countryName>Austria</countryName> <lat>47.01</lat> <lng>10.2</lng> <timezoneId>Europe/Vienna</timezoneId> <dstOffset>2.0</dstOffset> <gmtOffset>1.0</gmtOffset> <rawOffset>1.0</rawOffset> <time>2012-08-13 22:31</time> <sunrise>2012-08-13 06:14</sunrise> <sunset>2012-08-13 20:32</sunset> </timezone> </geonames>
You might want to tell Mark about this: http://www.theregister.co.uk/2008/07/23/shuttleworth_apple_challenge/ [*] It's Lion, so it's not Unix, it's just Un*x: http://www.opengroup.org/openbrand/register/
On 08/13/2012 04:39 PM, Guy Harris wrote:
On Aug 13, 2012, at 12:49 PM, James M Leddy wrote:
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this,
The desktop (well, laptop) Un*x[*] I'm running will, if I open System Preferences, disable "Set time zone automatically using current location", and drag the little blue location dot over towards China, offer a Time Zone of "China Standard Time" and list a number of cities in the drop-down list, including "Beijing - China" - and symlinks /etc/localtime to /usr/share/zoneinfo/Asia/Harbin.
The map it displays has "Geonames.org" on it.
says "The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge."; it's licensed under a Creative Commons Attribution 3.0 License.
According to
http://www.geonames.org/export/web-services.html
one service they offer is "Timezone":
Timezone
Webservice Type : REST Url : api.geonames.org/timezone? Parameters : lat,lng, radius (buffer in km for closest timezone in coastal areas), date (date for sunrise/sunset); Result : the timezone at the lat/lng with gmt offset (1. January) and dst offset (1. July) Example http://api.geonames.org/timezone?lat=47.01&lng=10.2&username=demo
This service is also available in JSON format : http://api.geonames.org/timezoneJSON?lat=47.01&lng=10.2&username=demo
Element: timezoneId: name of the timezone (according to olson), this information is sufficient to work with the timezone and defines DST rules, consult the documentation of your development environment. time: the local current time rawOffset: the amount of time in hours to add to UTC to get standard time in this time zone. Because this value is not affected by daylight saving time, it is called raw offset. gmtOffset: offset to GMT at 1. January (deprecated) dstOffset: offset to GMT at 1. July (deprecated)
so it appears that it translates a location to, among other things, an Olson database name. The example URL is for some location in Austria, as the XML that comes back is
<geonames> <timezone tzversion="tzdata2012c"> <countryCode>AT</countryCode> <countryName>Austria</countryName> <lat>47.01</lat> <lng>10.2</lng> <timezoneId>Europe/Vienna</timezoneId> <dstOffset>2.0</dstOffset> <gmtOffset>1.0</gmtOffset> <rawOffset>1.0</rawOffset> <time>2012-08-13 22:31</time> <sunrise>2012-08-13 06:14</sunrise> <sunset>2012-08-13 20:32</sunset> </timezone> </geonames>
I'm assuming you're using our distro? See my response to Paul. Even though we've done all this work we're still getting reports from partners in China that it isn't good enough.
You might want to tell Mark about this:
http://www.theregister.co.uk/2008/07/23/shuttleworth_apple_challenge/
[*] It's Lion, so it's not Unix, it's just Un*x:
Okay, I'll admit I wasn't including Apple as one of the desktop Unicies. I also have no idea what their time-zone picker looks like. My interest in this is mostly in solving this problem for the open source Unicies.
On Aug 13, 2012, at 1:49 PM, James M Leddy wrote:
Okay, I'll admit I wasn't including Apple as one of the desktop Unicies.
It is a desktop Un*x, so it should be included - especially if Mark's using it as the benchmark....
I also have no idea what their time-zone picker looks like. My interest in this is mostly in solving this problem for the open source Unicies.
Well, yes, but that doesn't mean you shouldn't try to do as well as Apple (and not do so without knowing what Apple's doing). I suspect most OS X users have no clue what's in /usr/share/lib/zoneinfo or what /etc/localtime links to, and they *shouldn't have to*. If Ubuntu's to be as pretty as OS X, most Ubuntu users shouldn't have to know that, either. The setting of TZ and/or what /etc/localtime links to should be a detail that only geeks need to care about, just as the setting of LANG is. en_US.UTF-8 needn't be prettified to "English-United States.UTF-8" for the benefit of people unfamiliar with the ISO codes in question; TZ needn't be prettified for the benefit of people who don't know the way the TZ database is structured.
On 2012-08-13 16:39, Guy Harris wrote:
On Aug 13, 2012, at 12:49 PM, James M Leddy wrote:
* The common proposed fix is that we should be using "human presentable" names and have a mapping from these names to the actual timezones. Since that proposal, indeed since the inception of desktop Linux/Unix, no one (as far as I know) has actually done this, The desktop (well, laptop) Un*x[*] I'm running will, if I open System Preferences, disable "Set time zone automatically using current location", and drag the little blue location dot over towards China, offer a Time Zone of "China Standard Time" and list a number of cities in the drop-down list, including "Beijing - China" - and symlinks /etc/localtime to /usr/share/zoneinfo/Asia/Harbin.
The map it displays has "Geonames.org" on it.
says "The GeoNames geographical database covers all countries and contains over eight million placenames that are available for download free of charge."; it's licensed under a Creative Commons Attribution 3.0 License.
According to
http://www.geonames.org/export/web-services.html
one service they offer is "Timezone":
Timezone
Webservice Type : REST Url : api.geonames.org/timezone? Parameters : lat,lng, radius (buffer in km for closest timezone in coastal areas), date (date for sunrise/sunset); Result : the timezone at the lat/lng with gmt offset (1. January) and dst offset (1. July) Example http://api.geonames.org/timezone?lat=47.01&lng=10.2&username=demo
This service is also available in JSON format : http://api.geonames.org/timezoneJSON?lat=47.01&lng=10.2&username=demo
Element: timezoneId: name of the timezone (according to olson), this information is sufficient to work with the timezone and defines DST rules, consult the documentation of your development environment. time: the local current time rawOffset: the amount of time in hours to add to UTC to get standard time in this time zone. Because this value is not affected by daylight saving time, it is called raw offset. gmtOffset: offset to GMT at 1. January (deprecated) dstOffset: offset to GMT at 1. July (deprecated)
Geonames.org only specifies offsets as of Jan 1st and July 1st, so it is not very usable for accurate timezone info, but it does use the Olson tz database names. My own product, Time Zone Master, uses the place names and zone names in geonames.org to determine the zone, but then uses the tz database to determine accurate timezone data. Dp
On Aug 13, 2012, at 2:25 PM, David Patte ₯ wrote:
Geonames.org only specifies offsets as of Jan 1st and July 1st, so it is not very usable for accurate timezone info, but it does use the Olson tz database names. My own product, Time Zone Master, uses the place names and zone names in geonames.org to determine the zone,
...which exactly what's being discussed here - finding a way to map locations to time zone names, so that the time zone names can be treated solely as geek-friendly strings. As you indicate, the geonames.org database would suffice for that function; we're not talking about using it to convert UTC to local time, we're just talking about using it to determine the appropriate Olson time zone name for a location.
but then uses the tz database to determine accurate timezone data.
...which is what the systems being talked about here (various Un*x systems) do (use the tz database for the localtime() and mktime() APIs).
At 2012-08-13 13:39, Guy Harris wrote:
According to
http://www.geonames.org/export/web-services.html
one service they offer is "Timezone":
Timezone
Webservice Type : REST Url : api.geonames.org/timezone? Parameters : lat,lng, radius (buffer in km for closest timezone in coastal areas), date (date for sunrise/sunset); Result : the timezone at the lat/lng with gmt offset (1. January) and dst offset (1. July) Example http://api.geonames.org/timezone?lat=47.01&lng=10.2&username=demo
This seems like a decent solution. If using the online APIs, to search for a particular placename, use http://api.geonames.org/search?name=xxxxx . To avoid a second API call to lookup the timezone from the resulting lat/lon, you can specify the style=FULL param, which will include the <timezone> element in the result. Also, if the search yields multiple results and you didn't spec style=FULL in the search query, get the record selected by the user by geonameId with http://api.geonames.org/get?geonameId=nnnnn&style=FULL . It's probably worthwhile to download the database and check for accuracy of the lat/lon mapping. A couple of spot checks with US state borders showed there _might_ be some issue with accuracy. -- Alan Mintz <Alan_Mintz+TZ_IANA@Earthlink.net>
On Aug 14, 2012, at 8:07 AM, Alan Mintz wrote:
It's probably worthwhile to download the database and check for accuracy of the lat/lon mapping. A couple of spot checks with US state borders showed there _might_ be some issue with accuracy.
It is, as far as I know, an open project, so if there are any inaccuracies, they should be sent updates.
participants (16)
-
Alan Mintz -
Clive D.W. Feather -
David Patte ₯ -
Derick Rethans -
Garrett Wollman -
Guy Harris -
James M Leddy -
John Hawkinson -
John Haxby -
Jonathan Leffler -
Mark Davis ☕ -
Paul Eggert -
Paul_Koning＠Dell.com -
Random832 -
sdaoden＠gmail.com -
Ted Cabeen