FW: IANA time zone registration - proposal

Tue Jan 18 00:43:26 UTC 2005

This is AWESOME - Thanks! - Replies / comments embedded below...

Paul Eggert wrote:
>>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.

In the past I was told that some time zones have geographic holes
in them.  And it was suggested by a cartographer in the CALSCH
mailing list that it would make the data easier to use by them.
As in if time-zone-x was surrounded entirely by time-zone-y.
then time-zone-y has a hole in it. This data is optional and
was simply on the list to make the cartographers happier.

Maybe the names 'include' and 'exclude' should be used
instead of 'add' and 'delete'.

> 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.

There is an open source tool (vzic. I have a copy at
http://INET-Consulting.com/vzic-1.2.tgz ) that converts the
TZ database to iCalendar format. I have and will do more
tweaks to adjust it for this specification.

It can be run at any time.

> 
> 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?

The attempt will be to convert them all using the tweaked
open source tool.

> 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?

Straight conversion from the TZ database.

> 
>>   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.

Thanks -  I did not notice that. I'll add optional "sub-regions"'s.

> 
>>   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.

When I ran VZIC I told it to start at 1970 so the sample
would be short. I'll add the phrase 'factious example'
to that example and change the name from Boise.

> 
> 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.

By enumerated property values it is referring to predefined iCalendar
names. The parameter AREA and its values ADD and DELETE are
case insensitive. As are TZID and TZURL. Where ADD and DELETE
are in the specification as enumerated values for AREA.

TZID values are non-enumerated values. So TZID values
are currently case sensitive UTF-8 characters.
I have been told they can accommodate any known char-set.

It can go ether way, what do you guys think it should be?

Much if that text is from the iCalendar spec, I'll tweak it to
be specific to this specification.

> 
>>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?

I'll remove - thanks.

> 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

I will - thanks!

The NAME property is being defined in iCalendar and it takes
on the form:

	NAME:LANG=FR_ca:a name in French Canadian as an example.

And multiple NAME properties are allowed per object . This I think
should work for alternate names or aliases.

> 
>>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.

If it becomes corrupt, it can be regenerate from scratch using the VZIC
tool.

I am not sure IANA wants every application that starts up to hit it
for time zones changes. I would think that it might be a good idea
to have a server.  This proposal is for a repository or source
if iCalendar time zone information, not a service. (Unless they
say it is okay)

> 
> 
>>        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.

Thanks!

> 
>>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.

Aliases - great idea (NAME above)

If the draft becomes a registry, my plan is to put all of the
current names in the registry.

> 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.

Thanks again!

> 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.

Great idea. His name was the point of contact when I first
looked YEARS ago, and the name stuck. It will be changed to 'TZ database'.

I asked Mr. Olson if he would like to co-author this specification
to give it a more legitimize look.  I offer you the same proposal.
I'll do the editing and you can supply whatever you think is need in the
spec. History, issues, problems, ... Yes/No/Maybe ?

THANKS!

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug at Royer.com                 | Office: (208)612-4638
http://Royer.com               | Fax:    (866)594-8574
                                | Cell:   (208)520-4044

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mm.icann.org/pipermail/tz/attachments/20050117/e547406e/smime-0001.p7s 