Localization Facilitation

[Paul Eggert]

Chuck Soper <chucks at lmi.net> writes:

> Many Olson TZIDs simply do not localize well. I believe that the
> Olson TZIDs were not designed with localization in mind.

I'm not sure what you mean here.  TZIDs are merely identifiers for
regions of the globe.

> I suggest a zoneMeta.tab file (very similar to zone.tab) be created
> for the propose of facilitating localization. Such a file could
> include the following columns:
>
>   - ISO 3166-1
>   - latitude/longitude (from zone.tab)
>   - Olson TZID
>   - city or place name

This is all in zone.tab now, for English only.  The city or place name
should be localized of course.

>   - sub-division (i.e. state, province, prefecture, or kingdom)

Often the TZID subdivisions are ad hoc; this reflects the ad hoc
nature of time zone and DST political decisions.  For the best TZ
subdivision data I know of, please see Gwillim Law's Statoids
<http://www.statoids.com/statoids.html>.  Another source is Oscar van
Vlijmen's Time zone boundaries for multizone countries
<http://home-4.tiscali.nl/~t876506/Multizones.html>.

>   - time zone name, general (e.g. Eastern Time)
>   - time zone name, specific if is exists
>             (e.g. Eastern Standard Time - Indiana - most locations)
>   - time zone name, std (e.g. Eastern Standard Time)
>   - time zone name, dst (e.g. Eastern Daylight Saving Time)

This is a different table, one that is not currently addressed
explicitly by the Olson database.  There is not a 1-1 correspondence
between time zone IDs and these names; it's a different relation.

Also, there is widespread disagreement over what the names are, in any
particular locale.  Different Australians disagree about what the
Australian English names are for their time zones, for example.  I
don't envy the job of people who would have to compile this
information.  (This is a polite way of saying that I'm skeptical about
whether anybody's going to do it.  :-)

>   - historic (yes/no)

An Olson Time zone identifier corresponds to a set of clocks that have
used the same civil time since 1970, so I don't know what you mean by
this attribute.  Are you referring to discontinued identifiers?

> additionally there could be columns to track if a particular time
> zone is within another time zone.

Olson TZIDs are either disjoint, or aliases.  There are no parents.
Perhaps this should be changed, but it would have to be designed carefully.

> Currently, time zone abbreviations are not unique (e.g. EST) and
> need to be associated with both an ISO 3166-1 code and an Olson
> TZID.

Currently, to generate a time zone abbreviation, you need (1) an Olson
TZID and (2) the UTC time stamp that you want the time zone
abbreviation for.  A single Olson TZID can map to many time zone
abbreviations.

>   - Should the tz database attempt to maintain or track ISO 3166-1
> codes that are either obsolete or do not have an associated time zone?

iso3166.tab tracks all the current ISO 3166-1 identifiers.  We haven't
seen any need to worry about obsolete codes.

>   - Should XML or XLIFF be considered for meta data only?

That's an interchange issue, not a schema issue.  The schema is more
important.  The source data can be stored in a simple text file, as now.

> I'm interested to find about the status of this localization and to
> find a way to keep informed of the progress.

I suggest contacting Mark Davis.