Date: Fri, 12 Oct 2012 23:19:19 +1100 From: Walter <walter.stanish@gmail.com> Message-ID: <CACwuEiM8=UeXjBWBrMr10vLswWFYZdwzr1bYxdX7MHJxi-AfOA@mail.gmail.com> | That's an understandable take, however consider the other side: | - ICANN's mandate is global and whilst its operating language may | very well be English, You're preaching to the converted, I have no doubt that the work needs to be done, it is just that I am not qualified to do it, and the mandate for this group does not necessarily attract those who do. | and tz has hobbled-along on a broken identifier scheme for some time, No, its identifier scheme is just fine. You're just trying to use it for something it wasn't designed to do, and then claiming it is broken because it doesn't meet your need. That's unreasonable - go design the identifier scheme that is needed for your purpose (or join the people already doing that), and we can continue just making sure that the data is correct, which is our role. | it seems somewhat difficult to dismiss i18n requirements, | especially those affecting some huge percentage of humanity No-one is dismissing the requirements, but we cannot do everything (there are lots of projects more important to even bigger percentages of humanity that we're not working on either.) | Some of those issues that tz is failing to solve right now are: | - Grouping of historical timezones in to single logical entities Because that would devalue the project, if anything we'd more likely move the cut-off point beyond which we currently ignore differences (somewhat arbitrarily set at 1970 - the unix time epoch) backwards, causing some of the zones we currently have to split. The chances of ever combining zones (in any way) (with the sole exception of a split made based on what turns out to be incorrect information) are close to nil. Give up on that one. | - Timezone (or timezone group) names We have names. The names we have work for their purpose. | - i18n of the above Someone else's problem. We understand time, not international naming. Others do the latter. | - The tz data set has already overstepped the raw tz data purpose and | branched out in to providing useful, (arguably less) closely related | information such as associated lat/long and city names. We deal with lat/long because that gives us local mean times, as used before standardised regional times were in use. Note that the lat/long we deal with are for points, not regions (some others have worked on the latter, we don't). The city names are just our naming convention. | In doing so, | it has broadened its scope beyond raw tz data to closely tz-related | data that is useful in implementing tz data based systems. Basically, | tz is a database, and the name of the tz's themselves should be a core | feature of that database. Absolutely, but the names for this purpose are internal database names, used to unambiguously select a particular set of data - that's all they're intended for, they are not supposed to be the user interface. I sometimes believe we should delete all the Australia/Melbourne Eurpoe/London America/New_York type names, and rename the zones as TZ1 TZ2 TZ3 ... Those would work just as well (though be harder to remember, and perhaps cause confusion on occasion) and would make it much clearer that people who do UI's should be providing a better interface than "select one of these names" for timezone selection (some already do, but they're a minority). | If a result were achieved here, however, it would be helpful to many | more people in the sense that it would be more likely to become | available to all related libraries and systems, That's less likely than you'd think. And certainly no more likely (perhaps even less likely) coming from a group with little expertise in the area. | Is this not in line with ICANN's "mission of technical coordination"?* Note that this group existed long before any involvement with ICANN - they just offered to be a host, but if you read the RFC that was created to enable the IANA involvement, you'll see that we remain almost completely independent. | OK. I would be worried however that this would cause issues with | existing systems utilizing the database -- because of the fact that | the tz database has apparently not provided enough structure within | the zone data to clearly delineate between different time zones | simultaneously in use within the same geographic region. We just define the zones, it is not, and never has been, our role to to attempt to work out what region uses any particular timezone. If there's a different timezone somewhere, and we can determine its parameters, we will define it, so it is available for use. Who uses it, and how they use it, is someone else's problem... | It seems to me that there is some kind of breakdown between cities as | geographic entities as principals for time zone affected regions The city names are just labels - they were chosen as we had (and I think still have) the belief that a city attempting to simultaneously use two different time settings (for common everyday use, specialised uses of different times are fine) would be an unworkable mess, and so that's so unlikely that using a city that happens to use a particular timezone as the name of that timezone seemed like a reasonable choice (and slightly more human friendly than TZ1 TZ2 TZ3 ...) | I just think that on the weight of it, historic timezones that few people | have even heard of are a virtually academic edge-case with regards to | the 1.399 billion people that use tz data for normal computing | purposes in China and couldn't care less about 20th century regulatory | hiccups. You mean they want it easy, rather than correct. That's not an uncommon desire, but it always always turns out to be a mistake. Do you plan on accepting responsibility for anything that goes wrong because of this "flexible" attitude to what is correct? | They don't have something that says "Beijing time", nor is | there even a means to link the five (!) disparate historic timezones | that may be useful for academics and specialists in to a single | timezone, which is the modern reality for 1.4 billion people. You mean they all see the same time when they look at their clocks, today. That's not a timezone, that's a clock setting. The timezone includes all the historical data, which isn't just of academic interest, it is reality. | That's clearly a bug, any way you look at it. As seen in an earlier | post on this thread, other zone lists have apparently taken some | initiative here. Why can't tz? I have no idea what bug you think it is, if you believe being correct is a bug, you have a vastly different view than I do. What other projects do depends upon their needs, if one of those is doing work more closely associated with your needs, perhaps you should join them. Their responsibility isn't to get the timezone data correct, ours is. That's what we will continue to do. | I'm not advocating the tz database care too much about UI. I am | merely advocating that it provides the fundamental requirement for any | timezone related program - a human readable name for the time zone in | question. We have that. TZ1 TZ2 ... would also qualify. What they're not is human friendly. That's something that we don't need. Others probably do. Once again, someone else's problem. | Right now, people use the identifier (eg: Asia/Shanghai) despite | problems with its use for this purpose. Asia/Shanghai is the tz database name for one of the zones that applies in China. If people want to select that zone when some other one really applies to them, I'd treat that as a failure of the UI (and someone else's problem). If the zone that they should select doesn't exist (which perhaps the ones you requested don't, and maybe should) then that is our problem. | That's because there's no | alternative provided except for the zone.tab comments, which are less | than uniformly suitable for presentation to (and translation for) end | users. zone.tab is an addendum to our primary purpose, personally I wouldn't mind if it simply went away, or perhaps responsibility for its maintenance shifted to some other group. | There should at least be a name. And if there's a name, in this day | and age, it should be multilingual. Fine, no argument, but we don't need that kind of name for our purposes. Others do. Once again, someone else's problem. | Right now the tz dataset, whilst successful, apparently remains a | database of identifiers for entities that cannot be presented to end | users, for wont of human readable names. No argument. So, go join the CLDR effort (or whatever it is) who apparently are working on, or have worked on, this issue (whoever they are). Our job is to make sure that all the data is present, available, and correct. We can't do everything, we have one particular role. It is quite specialised. In no way does it cover (even) everything related to times (we don't work on earth synchronisation, or leap seconds, or time scales, or ...) We just collect and publish timezone data - lists of discontinuities in the passage of time, as used locally on local wall clocks. Everything more than that is someone else's problem. kre