Network Working Group D. Royer
Internet-Draft IntelliCal LLC
Expires: July 29, 2005 January 28, 2005
Time Zone Registry
draft-royer-timezone-registry-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 July 29, 2005.
Copyright Notice
Copyright (C) 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.
Royer Expires July 29, 2005 [Page 1]
Internet-Draft Time Zone Registry January 2005
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 5
2.1 Formatting Conventions . . . . . . . . . . . . . . . . . . 5
2.2 Related Memos . . . . . . . . . . . . . . . . . . . . . . 6
2.3 International Considerations . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
4. Interoperability Considerations . . . . . . . . . . . . . . . 8
5. Registry TZID Value . . . . . . . . . . . . . . . . . . . . . 9
6. Registry NAME . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Registry TZURL Value . . . . . . . . . . . . . . . . . . . . . 12
8. Fetching a specific version of a VTIMEZONE . . . . . . . . . . 14
9. Fetching the newest version of a VTIMEZONE . . . . . . . . . . 15
10. iCalendar VTIMEZONE registry . . . . . . . . . . . . . . . . 16
11. AREA parameter . . . . . . . . . . . . . . . . . . . . . . . 17
12. Specifying geographic area covered - POLYGON . . . . . . . . 18
13. Initial Time Zone Names . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 27
Royer Expires July 29, 2005 [Page 2]
Internet-Draft Time Zone Registry January 2005
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 "VTIMEZONE" calendar component is not defined in this
specification and all usage here are simply examples. At the time of
this writing RFC-2445 is the authority for the "VTIMEZONE" calendar
component. The initial information in the registry will be from the
[TZ] database.
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.
The "TZID" property values are broken down into parts; region,
optional sub-regons, city, and revision. And they are separated
using the slash (/) character.
This example is using the factious America/BosieLike time zone that
was registered on January 15th, 2005 at 6:17:22 PM UTC:
Royer Expires July 29, 2005 [Page 3]
Internet-Draft Time Zone Registry January 2005
BEGIN:VCALENDAR
PRODID:-//IANA.ORG//NONSGML TZ VTIMEZONE DATABASE//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VTIMEZONE
TZID:/IANA.ORG/America/BoiseLike/20050115T181722Z
TZURL:ftp://iana.org/XXXXX/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
Royer Expires July 29, 2005 [Page 4]
Internet-Draft Time Zone Registry January 2005
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
[11].
The notation used in this memo is the ABNF notation of [12]. 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
[14] content type. While the iCalendar object is not a profile of
the [14] content type, it does reuse a number of the elements from
the [14] 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 [2] 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 [2]. Calendar components defined by this memo are
referred to with capitalized, quoted-strings of text. All calendar
components start with the letter "V". For example, "VTIMEZONE"
refers to the time zone calendar component.
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
Royer Expires July 29, 2005 [Page 5]
Internet-Draft Time Zone Registry January 2005
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 [2] specifications.
[2] - 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. Use of non-US-ASCII-compatible character sets is NOT
recommended.
Royer Expires July 29, 2005 [Page 6]
Internet-Draft Time Zone Registry January 2005
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.
Royer Expires July 29, 2005 [Page 7]
Internet-Draft Time Zone Registry January 2005
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.
Royer Expires July 29, 2005 [Page 8]
Internet-Draft Time Zone Registry January 2005
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.
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:
Royer Expires July 29, 2005 [Page 9]
Internet-Draft Time Zone Registry January 2005
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
Royer Expires July 29, 2005 [Page 10]
Internet-Draft Time Zone Registry January 2005
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 in a "VTIMEZONE" component.
By using the iCalenar "LANG" parameter, a "TZID" value can be
represented as aliases in muliple locales.
Property Name: NAME
Purpose: The NAME property allows for a TZID to have many possibly
locale specific names or aliases.
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.
Royer Expires July 29, 2005 [Page 11]
Internet-Draft Time Zone Registry January 2005
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/XXXXXX"
"/" tzregion *( "/" tzregion )
"/" tzcity ".ics"
Royer Expires July 29, 2005 [Page 12]
Internet-Draft Time Zone Registry January 2005
Example: The following is an example of this property that points to
the newest version of the time zone definitions.
TZURL:ftp://iana.org/XXXXXX/Indian/Reunion.ics
TZURL:ftp://iana.org/XXXXXX/Pacific/Pago_Pago.ics
TZURL:ftp://iana.org/XXXXXX/America/Indiana/Knox.ics
Royer Expires July 29, 2005 [Page 13]
Internet-Draft Time Zone Registry January 2005
8. 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/XXXXXX"
"/" tzregion *( "/" tzregion )
"/" tzcity
"/" tzrev ".ics"
For example the following are the URIs to get a specific version of
these time zones.
ftp://iana.org/XXXXXX/Pacific/Pago_Pago/20050114T162291Z.ics
ftp://iana.org/XXXXXX/Indian/Reunion/20050115T112522Z.ics
ftp://iana.org/XXXXXX/America/Indiana/Knox/20050222T130921Z.ics
Royer Expires July 29, 2005 [Page 14]
Internet-Draft Time Zone Registry January 2005
9. 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/XXXXXX"
"/" tzregion *( "/" tzregion )
"/" tzcity ".ics"
For example the following are the URIs to get a specific version of
these time zones.
ftp://iana.org/XXXXXX/Pacific/Pago_Pago.ics
ftp://iana.org/XXXXXX/Indian/Reunion.ics
Royer Expires July 29, 2005 [Page 15]
Internet-Draft Time Zone Registry January 2005
10. 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 register.
The TZURL property will be URL that will point to the newest version
of the time zone ".ics" file in the IANA registry.
Royer Expires July 29, 2005 [Page 16]
Internet-Draft Time Zone Registry January 2005
11. AREA parameter
The "POLYGON" property is being proposed to allow optional
information about the area to included or excluded from a geographic
area.
This 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
Royer Expires July 29, 2005 [Page 17]
Internet-Draft Time Zone Registry January 2005
12. Specifying geographic area covered - POLYGON
One of the issues brought up a few years ago on the CALSCH mailing
list was how to identify the area covered by a time zone. The issues
are that two or more time zone may overlap, and they might have areas
within them that are excluded, they have holes in their polygon.
So the "POLYGON" property is being proposed to allow 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:
Royer Expires July 29, 2005 [Page 18]
Internet-Draft Time Zone Registry January 2005
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.13.370000,
40.475000,111.586700,
37.276702,122.069020,
33.260654,122.006900
POLYGON;AREA=EXCLUDE:43.00,116.13.000000,
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:
http://iana.org/xxx/America/New_Yrk.geo
and
http://iana.org/xxx/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.
Royer Expires July 29, 2005 [Page 19]
Internet-Draft Time Zone Registry January 2005
POLYGON;AREA=INCLUDE;VALUE=URI:http://iana.org/xxx/America/New_York.geo
POLYGON;AREA=EXCLUDE:VALUE=URI:http://iana.org/xxx/America/Indiana/Knox.geo
And the "Americia/Indiana/Knox.ics" file might contain this:
POLYGON;AREA=INCLUDE:VALUE=URI:http://iana.org/xxx/America/Indiana/Knox.geo
Royer Expires July 29, 2005 [Page 20]
Internet-Draft Time Zone Registry January 2005
13. Initial Time Zone Names
The following time zone ID's will are in the initial submission.
They are all from the [TZ] database. They will all have "TZID"
property that matches the [TZ] database names and the 'tzrev' value
that is the submission date to IANA. (SAMPLE FOR NOW, FULL SET WILL
BE ADDED IN LATER DRAFTS)
Africa/Abidjan Africa/Accra
Africa/Addis_Ababa Africa/Algiers
Africa/Asmera Africa/Bamako
Africa/Bangui Africa/Banjul
Africa/Bissau Africa/Blantyre
Africa/Brazzaville Africa/Bujumbura
Africa/Cairo Africa/Casablanca
Africa/Ceuta Africa/Conakry
Africa/Dakar Africa/Dar_es_Salaam
Africa/Djibouti Africa/Douala
Africa/El_Aaiun Africa/Freetown
Africa/Gaborone Africa/Harare
Africa/Johannesburg Africa/Kampala
Africa/Khartoum Africa/Kigali
Africa/Kinshasa Africa/Lagos
Africa/Libreville Africa/Lome
Africa/Luanda Africa/Lubumbashi
Africa/Lusaka Africa/Malabo
Africa/Maputo Africa/Maseru
Africa/Mbabane Africa/Mogadishu
Africa/Monrovia Africa/Nairobi
Africa/Ndjamena Africa/Niamey
Africa/Nouakchott Africa/Ouagadougou
Africa/Porto-Novo Africa/Sao_Tome
Africa/Timbuktu Africa/Tripoli
Africa/Tunis Africa/Windhoek
America/Adak America/Anchorage
America/Anguilla America/Antigua
America/Araguaina America/Aruba
America/Asuncion America/Bahia
America/Barbados America/Belem
America/Belize America/Boa_Vista
America/Bogota America/Boise
America/Buenos_Aires America/Cambridge_Bay
America/Campo_Grande America/Cancun
America/Caracas America/Catamarca
America/Cayenne America/Cayman
America/Chicago America/Chihuahua
America/Cordoba America/Costa_Rica
Royer Expires July 29, 2005 [Page 21]
Internet-Draft Time Zone Registry January 2005
America/Cuiaba America/Curacao
America/Danmarkshavn America/Dawson_Creek
America/Dawson America/Denver
America/Detroit America/Dominica
America/Edmonton America/Eirunepe
America/El_Salvador America/Fortaleza
America/Glace_Bay America/Godthab
America/Goose_Bay America/Grand_Turk
America/Grenada America/Guadeloupe
America/Guatemala America/Guayaquil
America/Guyana America/Halifax
America/Havana America/Hermosillo
America/Indiana/Indianapolis America/Indiana/Knox
America/Indiana/Marengo America/Indianapolis
America/Indiana/Vevay America/Inuvik
America/Iqaluit America/Jamaica
America/Jujuy America/Juneau
America/Kentucky/Louisville America/Kentucky/Monticello
America/La_Paz America/Lima
America/Los_Angeles America/Louisville
America/Maceio America/Managua
America/Manaus America/Martinique
America/Mazatlan America/Mendoza
America/Menominee America/Merida
America/Mexico_City America/Miquelon
America/Monterrey America/Montevideo
America/Montreal America/Montserrat
America/Nassau America/New_York
America/Nipigon America/Nome
America/Noronha America/North_Dakota/Center
America/Panama America/Pangnirtung
America/Paramaribo America/Phoenix
America/Port-au-Prince America/Port_of_Spain
America/Porto_Velho America/Puerto_Rico
America/Rainy_River America/Rankin_Inlet
America/Recife America/Regina
America/Rio_Branco America/Santiago
America/Santo_Domingo America/Sao_Paulo
America/Scoresbysund America/Shiprock
America/St_Johns America/St_Kitts
America/St_Lucia America/St_Thomas
America/St_Vincent America/Swift_Current
America/Tegucigalpa America/Thule
America/Thunder_Bay America/Tijuana
America/Toronto America/Tortola
America/Vancouver America/Whitehorse
America/Winnipeg America/Yakutat
America/Yellowknife Antarctica/Casey
Royer Expires July 29, 2005 [Page 22]
Internet-Draft Time Zone Registry January 2005
Antarctica/Davis Antarctica/DumontDUrville
Antarctica/Mawson Antarctica/McMurdo
Antarctica/Palmer Antarctica/Rothera
Antarctica/South_Pole Antarctica/Syowa
Antarctica/Vostok Arctic/Longyearbyen
Asia/Aden Asia/Almaty
Asia/Amman Asia/Anadyr
Asia/Aqtau Asia/Aqtobe
Asia/Ashgabat Asia/Baghdad
Asia/Bahrain Asia/Baku
Asia/Bangkok Asia/Beirut
Asia/Bishkek Asia/Brunei
Asia/Calcutta Asia/Choibalsan
Asia/Chongqing Asia/Colombo
Asia/Damascus Asia/Dhaka
Asia/Dili Asia/Dubai
Asia/Dushanbe Asia/Gaza
Asia/Harbin Asia/Hong_Kong
Asia/Hovd Asia/Irkutsk
Asia/Istanbul Asia/Jakarta
Asia/Jayapura Asia/Jerusalem
Asia/Kabul Asia/Kamchatka
Asia/Karachi Asia/Kashgar
Asia/Katmandu Asia/Krasnoyarsk
Asia/Kuala_Lumpur Asia/Kuching
Asia/Kuwait Asia/Macau
Asia/Magadan Asia/Makassar
Asia/Manila Asia/Muscat
Asia/Nicosia Asia/Novosibirsk
Asia/Omsk Asia/Oral
Asia/Phnom_Penh Asia/Pontianak
Asia/Pyongyang Asia/Qatar
Asia/Qyzylorda Asia/Rangoon
Asia/Riyadh Asia/Saigon
Asia/Sakhalin Asia/Samarkand
Asia/Seoul Asia/Shanghai
Asia/Singapore Asia/Taipei
Asia/Tashkent Asia/Tbilisi
Asia/Tehran Asia/Thimphu
Asia/Tokyo Asia/Ulaanbaatar
Asia/Urumqi Asia/Vientiane
Asia/Vladivostok Asia/Yakutsk
Asia/Yekaterinburg Asia/Yerevan
Atlantic/Azores Atlantic/Bermuda
Atlantic/Canary Atlantic/Cape_Verde
Atlantic/Faeroe Atlantic/Jan_Mayen
Atlantic/Madeira Atlantic/Reykjavik
Atlantic/South_Georgia Atlantic/Stanley
Royer Expires July 29, 2005 [Page 23]
Internet-Draft Time Zone Registry January 2005
Atlantic/St_Helena Australia/Adelaide!
Australia/Brisbane Australia/Broken_Hill
Australia/Darwin Australia/Hobart
Australia/Lindeman Australia/Lord_Howe
Australia/Melbourne Australia/Perth
Australia/Sydney Europe/Amsterdam
Europe/Andorra Europe/Athens
Europe/Belfast Europe/Belgrade
Europe/Berlin Europe/Bratislava
Europe/Brussels Europe/Bucharest
Europe/Budapest Europe/Chisinau
Europe/Copenhagen Europe/Dublin
Europe/Gibraltar Europe/Helsinki
Europe/Istanbul Europe/Kaliningrad
Europe/Kiev Europe/Lisbon
Europe/Ljubljana Europe/London
Europe/Luxembourg Europe/Madrid
Europe/Malta Europe/Minsk
Europe/Monaco Europe/Moscow
Europe/Nicosia Europe/Oslo
Europe/Paris Europe/Prague
Europe/Riga Europe/Rome
Europe/Samara Europe/San_Marino
Europe/Sarajevo Europe/Simferopol
Europe/Skopje Europe/Sofia
Europe/Stockholm Europe/Tallinn
Europe/Tirane Europe/Uzhgorod
Europe/Vaduz Europe/Vatican
Europe/Vienna Europe/Vilnius
Europe/Warsaw Europe/Zagreb
Europe/Zaporozhye Europe/Zurich
Indian/Antananarivo Indian/Chagos
Indian/Christmas Indian/Cocos
Indian/Comoro Indian/Kerguelen
Indian/Mahe Indian/Maldives
Indian/Mauritius Indian/Mayotte
Indian/Reunion Pacific/Apia
Pacific/Auckland Pacific/Chatham
Pacific/Easter Pacific/Efate
Pacific/Enderbury Pacific/Fakaofo
Pacific/Fiji Pacific/Funafuti
Pacific/Galapagos Pacific/Gambier
Pacific/Guadalcanal Pacific/Guam
Pacific/Honolulu Pacific/Johnston
Pacific/Kiritimati Pacific/Kosrae
Pacific/Kwajalein Pacific/Majuro
Pacific/Marquesas Pacific/Midway
Pacific/Nauru Pacific/Niue
Royer Expires July 29, 2005 [Page 24]
Internet-Draft Time Zone Registry January 2005
Pacific/Norfolk Pacific/Noumea
Pacific/Pago_Pago Pacific/Palau
Pacific/Pitcairn Pacific/Ponape
Pacific/Port_Moresby Pacific/Rarotonga
Pacific/Saipan Pacific/Tahiti
Pacific/Tarawa Pacific/Tongatapu
Pacific/Truk Pacific/Wake
Pacific/Wallis Pacific/Yap
14 References
[1] Royer, D., "Calendar Access Protocol (CAP)", RFC XXXX - TBD,
XXXXX 2005.
[2] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object specification (iCalendar)", RFC 2445,
November 1998.
[3] "ISO 8601, Data elements and interchange formats-Information
interchange--Representation of dates and times International
Organization for Standardization", June 1988.
[4] "ISO/IEC 9070, Information Technology_SGML Support
Facilities--Registration Procedures for Public Text Owner
Identifiers Second Edition, International Organization for
Standardization", April 1991.
[5] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL", RFC 1738, December 1994.
[7] Alvestrand, H., "Tags for the Identification of Languages", RFC
1766, March 1995.
[8] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part Two: Media Types", RFC 2046, November
1996.
[10] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) - Part Four: Registration Procedures",
Royer Expires July 29, 2005 [Page 25]
Internet-Draft Time Zone Registry January 2005
RFC 2048, January 1997.
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[12] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[14] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
Directory Information", RFC 2425, September 1998.
[15] Olson, A., "Time zone code and data,
ftp://elsie.nci.nih.gov/pub/, updated periodically",
<ftp://elsie.nci.nih.gov/pub/>.
[16] "Internet Mail Consortium, vCalendar - The Electronic
Calendaring and Scheduling Exchange Format
http://www.imc.org/pdi/vcal-10.txt", September 1996,
<http://www.imc.org/pdi/vcal-10.txt>.
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
Royer Expires July 29, 2005 [Page 26]
Internet-Draft Time Zone Registry January 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Royer Expires July 29, 2005 [Page 27]