[tz] Proposal for a modern 'Collapsed' Namespace

Robert Elz kre at munnari.OZ.AU
Fri Oct 12 16:08:39 UTC 2012

    Date:        Fri, 12 Oct 2012 23:19:19 +1100
    From:        Walter <walter.stanish at gmail.com>
    Message-ID:  <CACwuEiM8=UeXjBWBrMr10vLswWFYZdwzr1bYxdX7MHJxi-AfOA at 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

  | 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

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.


More information about the tz mailing list