TOC 
Network Working GroupD. Royer
Internet-DraftIntelliCal LLC
Expires: January 9, 2006July 8, 2005

Time Zone Registry

draft-royer-timezone-registry-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 9, 2006.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

This is a submission for the creation of an new IANA Time Zones registration process. This is a registry for iCalendar "VTIMEZONE" calendar component information. Time zones and their definitions are required in order to schedule and synchronize meetings and software. The condition in which these time zones change are subject to civil authority rulings and are not always determinable by software algorithms.

This is intended to be a central repository for time zone information. The registry does not presume to be the authority for time zone information or rules. This register is simply a place where time zone definitions may be registered for public access.



Table of Contents

1.  Introduction
2.  Basic Grammar and Conventions
    2.1  Formatting Conventions
    2.2  Related Memos
    2.3  International Considerations
3.  Security Considerations
4.  Interoperability Considerations
5.  Registry TZID Value
6.  Registry NAME
7.  Registry TZURL Value
    7.1  Fetching a specific version of a VTIMEZONE
8.  Fetching the newest version of a VTIMEZONE
9.  iCalendar VTIMEZONE registry
10.  AREA parameter
11.  Specifying geographic area covered - POLYGON
12.  Initial Time Zones
13.  Updating Time Zones
14.  References
§  Author's Address
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

Many software vendors create time zone information for their applications. This information can sometimes be inconsistent with other applications or contain insufficient information when referring to times far in the past. 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.

Each time zone has a unique iCalendar time zone identifier (TZID). This document uses the iCalendar "LAST-MODIFIED" property in the iCalendar "VTIMEZONE" calendar component to track revisions of the data.

The initial information in the registry will be from the [TZ] database. New properties are defined in this memo.

When applications create information using a time zone is critical that the using applications have the same definitions of the time zone in order for the instances in time to match. For that reason the "TZID" property value will contain the revision information of the time zone name and the "TZURL" value will point to the specific revision of the time zone data.

When an iCalendar component is created, the originating software specifies the TZID, determines the revision they is being used, and include that TZID and revision information in the objects so that consumers of the objects know exactly which time zone definition and revision was used by the originator.

The "TZID" property values are broken down into parts; region, optional sub-regons, city, and revision. And they are separated using the slash (/) (ascii decimal value 47) character.

This example is using the factious America/BosieLike time zone that was registered on January 15th, 2005 at 6:17:22 PM UTC:


    BEGIN:VCALENDAR
    PRODID:-//IANA.ORG//NONSGML TZ VTIMEZONE DATABASE//EN
    VERSION:2.0
    METHOD:PUBLISH
    BEGIN:VTIMEZONE
    TZID:/IANA.ORG/TimeZone/America/BoiseLike/20050115T181722Z
    TZURL:ftp://iana.org/TimeZone/America/BoiseLike.ics
    LAST-MODIFIED:20050115T181722Z
    BEGIN:STANDARD
    TZOFFSETFROM:-0600
    TZOFFSETTO:-0700
    TZNAME:MST
    DTSTART:19701025T020000
    RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
    END:STANDARD
    BEGIN:DAYLIGHT
    TZOFFSETFROM:-0700
    TZOFFSETTO:-0600
    TZNAME:MDT
    DTSTART:19700405T020000
    RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
    END:DAYLIGHT
    END:VTIMEZONE
    END:VCALENDAR



 TOC 

2. Basic Grammar and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interoperated as described in [4] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

The notation used in this memo is the ABNF notation of [5] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.). Readers intending on implementing this format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo.

All numeric and hexadecimal values used in this memo are given in decimal notation.

All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated.

Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo.

The format for the iCalendar object is based on the syntax of the [7] (Howes, T., Smith, M., and F. Dawson, “A MIME Content-Type for Directory Information,” September 1998.) content type. While the iCalendar object is not a profile of the [7] (Howes, T., Smith, M., and F. Dawson, “A MIME Content-Type for Directory Information,” September 1998.) content type, it does reuse a number of the elements from the [7] (Howes, T., Smith, M., and F. Dawson, “A MIME Content-Type for Directory Information,” September 1998.) specification.

2.1 Formatting Conventions

The mechanisms defined in this memo are defined in prose. Many of the terms used to describe these have common usage that is different than the standards usage of this memo. In order to reference within this memo elements of the calendaring and scheduling model, core object [1] (Dawson, F. and D. Stenerson, “Internet Calendaring and Scheduling Core Object specification (iCalendar),” November 1998.) some formatting conventions have been used. Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" within the protocol defined by [1] (Dawson, F. and D. Stenerson, “Internet Calendaring and Scheduling Core Object specification (iCalendar),” November 1998.). Calendar components defined by this memo are referred to with capitalized, quoted-strings of text. For example, "VTIMEZONE" refers to the time zone calendar component. Usage of the term 'iCal' in this memo means RFC 2445 .

The properties defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "TZNAME" property refers to the iCalendar property used to convey the display name of the time zone. Property parameters defined by this memo are referred to with lowercase, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value.

2.2 Related Memos

Implementers will need to be familiar with several other memos that, along with this memo. Such as iCalendar [1] (Dawson, F. and D. Stenerson, “Internet Calendaring and Scheduling Core Object specification (iCalendar),” November 1998.) specifications.

[1] (Dawson, F. and D. Stenerson, “Internet Calendaring and Scheduling Core Object specification (iCalendar),” November 1998.) - Specifies the format for the "VTIMEZONE" calendar component.

This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts or definitions.

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. The "character name" is the authoritative description; (codepoint) is a reference to that character in US-ASCII or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set is used, appropriate code-point from that character set MUST be chosen instead.



 TOC 

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.



 TOC 

4. Interoperability Considerations

This document is intended to be compliant with the [iCAL] "VTIMEZONE" calendar component and will interoperate with any implementation that follows that specification. New properties are being registered as part of this memo.



 TOC 

5. Registry TZID Value

Within the time zone registry, the "TZID" property will be used as follows. This is compatible with the [iCAL] "TZID" property as here we only define the format of the value of the property.

Property Name: TZID

Purpose: This property specifies the text value that uniquely identifies the "VTIMEZONE" calendar component in the IANA registry. The value is case sensitive and is UTF-8 so it should be able to accomidate any locale.

Value Type: TEXT (in the format specified below)

Property Parameters: Non-standard property parameters can be specified on this property.

Conformance: This property MUST be specified in a "VTIMEZONE" calendar component that complies with this memo.

Description: This is the label by which a time zone calendar component is referenced by any iCalendar properties whose data type is either DATE-TIME, DATE, or TIME and not intended to specify a UTC or a "floating" time. The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents an unique ID in a globally defined IANA time zone registry (this specification). Conforming applications MUST supply the 'tzrev' attribute shown below in the "TZID" property value. The "TZID" property value points to a specific version of the time zone.

All of the 'tzregion', 'tzcity', and 'tzrev' values are case sensitive.

Format Definition: This property is defined by the following notation:

     tzid               = "TZID" tzidpropparam ":"
                           ianatzidprefix
                       "/" tzregion *( "/" tzregion )
                       "/" tzcity
                       "/" tzrev CRLF

     tzidpropparam      = *(";" xparam)

     ianatzidprefix     = "/IANA.ORG"

     tzregion           = < region names as used in the [TZ] databaee >
                        ; Examples are "Africa", "America", "Asia"
                        ;  "Europe", "Indian" "Pacific"

     tzcity             = <the name of a city in the tzregion>

     tzrev              = date-time "Z"

     date-time          = <as defined in iCalendar>

Example: The following are examples of globally unique time zone identifiers as defined by this specification:


     TZID:/IANA.ORG/Indian/Reunion/20050115T112522Z

     TZID:/IANA.ORG/Pacific/Pago_Pago/20050114T162291Z

     TZID:/IANA.ORG//America/Indiana/Knox/20050114T162291Z



 TOC 

6. Registry NAME

One time zone definition may have more than one name or alias. And time zone names might be in a non US-ASCII locale. So this "NAME" property will be allowed multiple time zone names in a "VTIMEZONE" component. By using the iCalenar "LANG" parameter, a "TZID" value can be represented as aliases in muliple locales and multiple names or aliases.

For example "PST" could be a alias for "America/Los_Angeles". Note that many of the TZID's in use today are not unique so it is possible that multiple registered TZIDs have aliases that are the same as aliases for other registered TZIDs. This memo and the registration process is inspired by the desire to solve that problem. The registered TZID MUST BE unique in the registry. The "NAME" values do not have to be unique across registered TZID's.

Property Name: NAME

Purpose: The NAME property allows for a TZID to have many possibly locale specific names or aliases for the same definition.

Value Type: TEXT

Property Parameters: The "LANG" parameter and non-standard property parameters can be specified on this property.

Conformance: This property can be specified in a "VTIMEZONE" calendar component.

Description: Multiple NAME properties may be in a "VTIMEZONE" calendar compoennt, each must be unique. Each "NAME" property MUST include a "LANGUAGE" parameter specifing the locale where the "NAME" property value would be used. There may be multiple "NAME" properties with the same "LANGUAGE" parameter value as long as those "NAME" property values are unique. When in a "VTIMEZONE" calendar component then they are alias nams for the "TZID" property value. Note that the "STANDARD" and "DAYLIGHT" calendar components use zero or more of the locale specific "TZNAME" property as aliases as defined in iCalendar.

Format Definition: The property is defined by the following notation:


     aliasname      = "NAME" nameparam ":" localeName CRLF

     nameparam = langparam *(";" xparam)

     langparam = < As defined in iCalendar >

     localName = < Single line text used as name or alias of TZID >a

Examples.


   NAME;LANGUAGE=us-EN:PST
   NAME;LANGUAGE=us-EN:Us/Pacific



 TOC 

7. Registry TZURL Value

Within the time zone registry, the "TZURL" property will be used as follows. This is compatible with the [iCAL] "TZURL" property as here we only define the format of the value of the property.

Property Name: TZURL

Purpose: The TZURL provides a means for a VTIMEZONE component to point to a network location that can be used to retrieve an up-to- date version of itself.

Value Type: URI

Property Parameters: Non-standard property parameters can be specified on this property.

Conformance: This property can be specified in a "VTIMEZONE" calendar component.

Description: The TZURL provides a means for a VTIMEZONE component to point to a network location that can be used to retrieve an up-to- date version of itself. This provides a hook to handle changes government bodies impose upon time zone definitions. Retrieval of this resource results in an iCalendar object containing a single VTIMEZONE component and a METHOD property set to PUBLISH. Conforming applications MUST NOT supply the 'tzrev' attribute shown in the "TZID" property value above. The "TZURL" property value points to the newest version of the time zone named in the "TZID" parameter.

All of the fetch value is case sensitive.

All of the 'tzregion' and 'tzcity' values are case sensitive. And the '.ics' is in lower case.

Format Definition: The property is defined by the following notation:


     tzurl      = "TZURL" tzurlparam ":" ianatzuri CRLF

     tzurlparam = *(";" xparam)

     ianatzuri  = "ftp://iana.org/TimeZone"
                  "/" tzregion *( "/" tzregion )
                  "/" tzcity ".ics"


Example: The following is an example of this property that points to the newest version of the time zone definitions.


  TZURL:ftp://iana.org/TimeZone/Indian/Reunion.ics

  TZURL:ftp://iana.org/TimeZone/Pacific/Pago_Pago.ics

  TZURL:ftp://iana.org/TimeZone/America/Indiana/Knox.ics

7.1 Fetching a specific version of a VTIMEZONE

An application that wishes to get a specific version of a registered "VTIMEZONE" component creates the FTP url as follows:

All of the 'tzregion', 'tzcity', and 'tzrev' values are case sensitive and '.ics' is lower case.


     fetchuri  = "ftp://iana.org/TimeZone"
                 "/" tzregion *( "/" tzregion )
                 "/" tzcity
                 "/" tzrev ".ics"

For example the following are the URIs to get a specific version of these time zones.


  ftp://iana.org/TimeZone/Pacific/Pago_Pago/20050114T162291Z.ics

  ftp://iana.org/TimeZone/Indian/Reunion/20050115T112522Z.ics

  ftp://iana.org/TimeZone/America/Indiana/Knox/20050222T130921Z.ics



 TOC 

8. Fetching the newest version of a VTIMEZONE

An application that wishes to get the newest version of a registered "VTIMEZONE" component creates the FTP url as follows:

Both the 'tzregion' and 'tzcity' values are case sensitive and '.ics' is lower case.


     fetchnewuri  = "ftp://iana.org/TimeZone"
                    "/" tzregion *( "/" tzregion )
                    "/" tzcity ".ics"

For example the following are the URIs to get a specific version of these time zones.


  ftp://iana.org/TimeZone/Pacific/Pago_Pago.ics

  ftp://iana.org/TimeZone/Indian/Reunion.ics



 TOC 

9. iCalendar VTIMEZONE registry

Each time zone is an [iCAL] "VTIMEZONE" calendar component. The [iCAL] "TZID" property value will be unique in the IANA registry and will be prefixed with "/IANA.ORG/" to identify them as being part of the registery.

The TZURL property will be URL that will point to the newest version of the time zone ".ics" file in the IANA registry.



 TOC 

10. AREA parameter

The "POLYGON" property allows optional information about the area to included or excluded from a geographic area.

The "AREA" parameter specifies if the values of the "POLYGON" property are to be included or excluded from the geographic region described in the "VTIMEZONE" component.

Parameter Name: AREA

Purpose: To specify if the area is to be included or excluded from the geographic region.

Value Type: TEXT

Conformance: This property MUST BE specified in a "POLYGON" property.

Description: If the AREA value is "INCLUDE", then the area is to be added to the geographic region of area covered. If the value is "EXCLUDE" then the area is to be deleted from the geographic area covered.

Format Definition: This property is defined by the following notation:

     area       = ";" "AREA" "=" ( "INCLUDE" / "EXCLUDE")

Example: The following are examples of the usage of the "AREA" parameter:


     POLYGON;AREA=INCLUDE: ...lat/long..sets..of..data
     POLYGON;AREA=EXCLUDE: ...lat/long..sets..of..data



 TOC 

11. Specifying geographic area covered - POLYGON

The "POLYGON" property allows optional information about the area to include or exclude from a geographic area.

Property Name: POLYGON

Purpose: This property specifies the geographic area covered by a time zone.

Value Type: TEXT (Comma separated latitude/longitude values)

Property Parameters: The "AREA" parameter is the only parameter allowed.

Conformance: This property MAY be specified in a "VTIMEZONE" calendar component.

Description: The values are a comma separated set of longitude and latitude values to six decimal places. There must be at least three sets and will be as many as needed to specify the area covered by the polygon. Using the required "AREA" parameter an area can be included or exclude from the time zone area covered. A time zone may have one or more non-overlapping areas. And a time zone might have holes in it.

The value type is TEXT and can be overwriten to be a "URI" value type, so that the definiton can point to a separate file that describes the geographic region that is convered. The URI MUST point to a file that only contains a list of at least three comma separated 'geopoint' entries as shown in this section. And the URI MUST point to a publicly available file.

The values start at one geographic point and continue in a counter clockwise direction. The first point MUST NOT be repeated as the last point. If drawn on paper, a line would start at the first point, continue to the second point, and to each next point. Then a line would be drawn from the last point to the first point.

Format Definition: This property is defined by the following notation:

     polygon     = "POLYGON" polytzparam ":"
                   geopoint "," geopoint "," geopoint *("," geopoint)
                   CRLF

     polytzparam =  area  *( ";" "VALUE" "=" "URI" )

     geopoint    = lat "," lon

     lat         = <latitude with six digits to right of the decimal>

     lon         = <longitude with six digits to the right of the decimal>

Example: The following is an example of a geographic region included, and a section excludes on the second entry (if done correctly, the time zone area in this example would be like a donut with a hole in the center).


     POLYGON;AREA=INCLUDE:43.336600,116.370000,
      40.475000,111.586700,
      37.276702,122.069020,
      33.260654,122.006900

     POLYGON;AREA=EXCLUDE:43.00,116.13000000,
      40.30000,111.500000,
      37.20000,122.069000,
      33.20000,122.006000

Now assume you have two text files with at least three comma separated 'geopoint' entries:


    ftp://iana.org/TimeZone/America/New_Yrk.geo

and


    ftp://iana.org/TimeZone/America/Indiana/Knox.geo

By using a "URI" value type, these can be in the "VTIMEZONE" component and point to a files that really contain the time zone geographic region. So the "Americla/New_York.ics" file might contain this if the "America/New_York" time zone is not valid in the "America/Indiana/Knox" time zone.


   POLYGON;AREA=INCLUDE;VALUE=URI:ftp://iana.org/TimeZone/America/New_York.geo
   POLYGON;AREA=EXCLUDE:VALUE=URI:ftp://iana.org/TimeZone/America/Indiana/Knox.geo

And the "Americia/Indiana/Knox.ics" file might contain this:


   POLYGON;AREA=INCLUDE:VALUE=URI:ftp://iana.org/TimeZone/America/Indiana/Knox.geo



 TOC 

12. Initial Time Zones

The initial time zones submitted will be from the latest [TZ] database.



 TOC 

13. Updating Time Zones

This process is TBD and will be developled by consulting with IANA.



 TOC 

14. References

[1] Dawson, F. and D. Stenerson, “Internet Calendaring and Scheduling Core Object specification (iCalendar),” November 1998.
[2] “ISO 8601, Data elements and interchange formats-Information interchange--Representation of dates and times International Organization for Standardization,” June 1988.
[3] “ISO/IEC 9070, Information Technology_SGML Support Facilities--Registration Procedures for Public Text Owner Identifiers Second Edition, International Organization for Standardization,” April 1991.
[4] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.
[5] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.
[6] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” January 1998.
[7] Howes, T., Smith, M., and F. Dawson, “A MIME Content-Type for Directory Information,” September 1998.
[8] Olson, A., “Time zone code and data, ftp://elsie.nci.nih.gov/pub/, updated periodically.”


 TOC 

Author's Address

  Doug Royer
  IntelliCal LLC
  267 Kentlands Blvd., #3041
  Gaithersburg, MD 20878
  USA
Phone:  +1-208-612-4638
Email:  Doug@IntelliCal.net
URI:  http://Royer.com


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment