FW: IANA time zone registration - proposal

Paul Eggert eggert at CS.UCLA.EDU
Mon Jan 17 23:47:37 UTC 2005


> From: Doug Royer [mailto:Doug at Royer.com] 
> Sent: Monday, January 17, 2005 2:12 PM
>
> I am adding the POLYGON property targeted for the -01 version that has an
> ADD/DELETE parameter to allow for the optional inclusion of
> latitude/longitude geographic areas to be included that include (add) and
> exclude (delete) areas from the time zone geographic region (again from the
> CALSCH mailing list discussions).

It would be interesting to see a database containing some of that
information, as a sample, as I don't offhand follow why DELETE would
be useful.

Here are some comments on draft 00.

>    By creating an IANA registry, the same information will be
>    available to any vendor.  In addition there is revision control
>    in the database so vendors will know if they have the latest
>    data.

What process will be used to keep the IANA registry in sync with
further changes to the TZ database?  Here I am referring not only to
changes in the data (e.g., Israel will probably change its rules again
this year), but also the addition of new names, renaming entries,
backwards compatibility for old names, etc.

Also, exactly which subset of tzdata will be used?  Will the registry
store only the rules that are compatible with the rules used today?
(That's what the Boise example does, I think -- it omits DST rules in
effect before 1987.)  Or will the registry attempt to capture all the
rules in tzdata?

Will the registry use names that are not in tzdata?  What general
rules of thumb will the registry use to avoid collisions with new
tzdata names in the future?

>    The "TZID" property values are broken down into three parts; region,
>    city, and revision.  And they are separated using the slash (/)
>    character.

The tz database is not restricted to two-part names; in some of the
more complicated cases like Indiana and Argentina, there are
three-part names.  Examples include America/Argentina/San_Juan and
America/Indiana/Knox (the latter is given as an example in the
"Initial Time Zone Names" section of draft 00).  The TZID property
values should therefore allow for an arbitrary number of parts of
name.

>    This example is using the America/Bosie time zone that was registered

Bosie -> Boise

The example data for Boise doesn't match what's in the TZ database.
Is this intended?  The example claims that the current rules have been
in effect since 1970, whereas actually they have been in effect only
since 1987.

What constraints does the proposed specification place on the
characters that can appear in TZID values, or in TZNAME values?
Please see the Theory file in the tz database for its limits on TZID
values (which are partly derived from portable POSIX file name
restrictions); you can look under "Here are the general rules used for
choosing location names".  For restrictions on TZNAME values, plese
see the "Time zone abbreviations" section in that file.

>    All names of properties, property parameters, enumerated property
>    values and property parameter values are case-insensitive.

Are TZID values case sensitive?  I'm not a VTIMEZONE expert so it's
hard for me to know.

> 2.3  International Considerations
> 
>    In the rest of this document, descriptions of characters are of the
>    form "character name (codepoint)", where "codepoint" is from the US-
>    ASCII character set.

I didn't see that notation used anywhere; perhaps this section is
redundant?

How would the registry handle alternate TZNAME values for different
locales?  Is there any plan for supporting "short names" or "long
names" for zones?  I suggest looking at the Time Zone Localization
proposal, at:

http://oss.software.ibm.com/cvs/icu/~checkout~/locale/docs/design/formatting/time_zone_localization.html

> 3.  Security Considerations
> 
>    There are no known security issues with this proposal as this is a
>    repository of information and not an over the wire protocol.

If the repository becomes corrupted, any security-related enforcement
that is based on local time (e.g., "you can access this site only from
9am-5pm local time") and which relies on the repository would become
suspect.

>         tzregion           = "Africa"  / "America" / "Asia" / "Europe"
>                              / "Indian" / "Pacific"

I would not hardwire the region names into the spec.  For one thing,
you missed some regions, e.g., "Atlantic".  For another, the list of
regions might change in the future.

> 8.  Initial Time Zone Names

Is the intent of the registry to store aliases?  For example, in the
tz database, Europe/Vatican is an alias for Europe/Rome.  You list
both entries, so I assume the intent is to store some aliases.  But
you omit some other aliases so it's not clear to me what rules you're
using to select a subset of the tz database's names.

Also, the initial names are a bit out of date: they use the old names
for Argentine zones, and they lack the Europe/Mariehamn link for the
Aaland Islands.

Another reference you should give is

Eggert, P. and Olson, A., "Sources for Time Zone and Daylight Saving
Time Data" <http://www.twinsun.com/tz/tz-link.htm>, updated
periodically.

A point of terminology: Arthur David Olson is responsible for the code
used to create and access the database, while I have maintained the
data itself for many years, and have served as the editor for almost
all the data that is currently present in it.  So for the purpose of
your proposal, the name "Olson database" is a bit of a misnomer, as
you don't really care about the code or the existing database format;
you care only about the data.  I'd prefer it if you called it the "tz
database" instead.



More information about the tz mailing list