Fw: Time Zone Names

Fri Oct 2 16:49:40 UTC 1998

I find this discussion on time zone names interesting as well as the
example of the country code qualifier. It highlights a large issue, namely
that of unambiguous identification and referencing of  "time zones" and in
an IT-enabled manner. In addition, it is likely that e-commerce will make
increasing use of date/time stamps in business transactions(e.g. closing
date/time for bid is XXX local time, or an identified/referenced time zone)
and the same in relation to digital signatures, certificates, key
management, etc.

Attached is a Canadian contribution to ISO standardization work of
relevance to this discussion and relates issues. Normally, I would have
provided the  URL but access to the ISO/IEC JTC1/SC32 web site requires
User ID and Password. Thus I attach a copy as a Word doc. Let me summarize
three key points:

1. In standardization work in relation of Open-edi, e-commerce, geomatics,
etc., one is becoming increasingly aware of the need for unambiguous,
unique and linguistically neutral identification and referencing of
"objects". As found in ISO 1087 "name" = "designation of an object by a
linguistic expression". Consequently, any object will (1) have multiple
names and (2) many of the "names" used to designate a real worl "object"
will be in the form of linguistic expresions which use -non-Latin
characters (e.g. Arabic, Chinese, Hebrew, Japanese, Cyrillic, etc.) This is
one reason why ISO/IEC 106464 (a.k.a.) will become a key IT-infrastructure
standard.  Thus "names" can be and are used to designate an object, they
are not that useful for unambiguous identification since often a name, i.e.
a character string (or alpha/neric string), is not unique. Here "Paris"
provides an example of several different real world objects having the same
name.[ A problem known as "polysemy"] We can add qualifiers and will likely
do but here I suggest cross-sectorial approach for refrencing rather that
each area doing its own thing.

2. It is my understanding that the problem of multiple linguistic
expression for the same geographic place name( e.g. London, Londres, Köln,
Keulen, Cologne,  Germany/Deutschland/Allemagne, etc.) is being addressed
by topnomy experts world-wide through the UN (I need to check this out but
maybe one of you knows more about this). It is my understanding that in the
end there will only be one single official name for each place in each
country in the language of that country as decided by the toponomy
commission in each country. Where the language of that country uses a
non-latin alphabet character set, that country is also expected to provide
one single Latin-alphabet based equivalent name. In Canada, which is a
biligual country (English/French), existing bilingual place names are
disappearing in favour of  uniligual ones, i.e. English or French (e.g.
Trois Rivières/Three Rivers is now only Trois Rivières). Further in Canada
(and likely inother countries as well), each place name, whether point,
area/polygons or linear (e.g. rivers),  is assigned a single lat/long
coordinate for referencing purposes. (For larger cities, lakes, provinces,
etc. this is an "abitrary" point, for river is is a lat/long coordinate
take from the headwater, etc. Where map surrounds/polygons delienate the
boundaries, these can then be referenced. In conclusion there is/should be
a linkage here to the manner in which one references time zones. (See
further the National Atlas of Canada and its Canadian Geographic Names Data
Base)

3. The ISO 3166 standard Parts 1 and 2 is not IT-enabled, the two letter
alpha codes are not stable can and do change (The IANA and Internet domain
names also has to address this problem but then underneath all the Internat
names are the numeric codes used for the actual routing and addressing
among the ISPs, IT-systems, etc.). The ISO 3166  the three digit numeric
country code is the most stable and also unique. The two alpha country
codes often gets mixed up with the two letter language codes and the three
letter alpha country codes with the three letter currency codes. They are
not the same and often not unqie. All these and related problems which
human beings used to filter out or write special programmes for to handle
are now coming out in spades via everyone's access and use of the Internet.
A systematic and IT-enabled approach to resolve this increasing mess is
needed. Added note: There is Paris the city and these is Paris the
"departement", there is New York the city and there is New York to state.
The problem is resolvable and may require less work than one would expect.

Enough said. I am doing some work in this field from an edi and e-commerce
perspective as well as that of the environment. If you think this is
important, have some ideas, know of other areas where addressing this would
be of use, etc. please let me know.

Trust this is of some help 

Regards - Jake Knoppers

P.S.I also agree that continent/citynames is not that useful. It neither
provides the unambiguity nor uniques required for referencing purposes. A
better solution would be along the following lines:

1. Reference the ISO 3166 standard
2. Always start with a Level one country code
3. The a level 2 administrative subdivision code (e.g. state, province,
lander, canton, etc)
4. The official name of the place according to the authoritative source,
i.e. Wien and not Vienna or Vienne, Köln (or Koln) but not Keulen, Cologne)
5. Optional the associated lat/long coordinate as assigned by the
authoritative source.
6. From a human interface needs and localization context, one would be free
to provide different linguistic equivalent designations, i.e. "names"

While such a solution requires a bit more data, it compensates by being
useful to  many other application areas as well as facilitating
cross-sectorial electronic data interchange.
----------
> From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
> To: tz at elsie.nci.nih.gov
> Subject: Re: Time Zone Names 
> Date: September 30, 1998 4:25 AM
> 
> Ken Pizzini wrote on 1998-09-30 00:22 UTC:
> > Markus Kuhn wrote:
> > >  As I have pointed out before, I don't like the
> > > continent prefix in the Olson/style names, therefore I do not want to
> > > make this particular syntax immortal in an ISO standard (I much
prefer
> > > just ":Paris" over "Europe/Paris").
> > 
> > Interesting example.  Is ``:Paris'' "Paris, France", or "Paris, Texas",
> > or perhaps one of the other half-dozen or so cities named Paris?
> 
> Remember that time zone names refer to the most populated area within a
> region with common time zone history. This rule should already resolve
> practically all ambiguities. If there are really two Paris that are both
> candidates for TZ entries as they are both most populated areas in
> different time zone regions, then they should get qualifiers added (or
> at least all but the largest one should). This way, all those little
> Paris clones in the US are not of concern any more, and "Paris" would be
> guaranteed to refer to the real big one under the Eiffel's tower.
> 
> To remove any ambiguity, we have the coordinates of the place, and a GUI
> TZ selector tools can easily indicate on a map what region we are
> talking about.
> 
> > I'm not particularly thrilled with the continent name either, but it
> > does serve a purpose.
> 
> But not very well. How many Paris are there in the US alone?
> 
> An ISO 3166-1 country code or where necessary ISO 3166-2 country/region
> code for those hypothetical cases where there could occur an ambiguity
> would serve this purpose much better. The continent names come from the
> file organization of the Olson DB, and this implementation detail should
> IMHO not leak through to the name space. That's why I am not particular
> happy with seeing iCalendar people making these continent/city names
> more permanent by quoting them in their standards.
> 
> If I had to design proper tz names from scratch, they might look more
> like
> 
>   fr.paris
>   us.tx.paris
> 
> Markus
> 
> -- 
> Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
> email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 32n0147.doc
Type: application/octet-stream
Size: 94720 bytes
Desc: 32n0147.doc (Microsoft Word 6.0 Document)
Url : http://mm.icann.org/pipermail/tz/attachments/19981002/923d6984/32n0147-0001.doc 