Internet Engineering Task Force (IETF) E. Lear Request for Comments: 6557 Cisco Systems GmbH BCP: 175 P. Eggert Category: Best Current Practice UCLA ISSN: 2070-1721 February 2012 Procedures for Maintaining the Time Zone Database
AbstractTime zone information serves as a basic protocol element in protocols, such as the calendaring suite and DHCP. The Time Zone (TZ) Database specifies the indices used in various protocols, as well as their semantic meanings, for all localities throughout the world. This database has been meticulously maintained and distributed free of charge by a group of volunteers, coordinated by a single volunteer who is now planning to retire. This memo specifies procedures involved with maintenance of the TZ database and associated code, including how to submit proposed updates, how decisions for inclusion of those updates are made, and the selection of a designated expert by and for the time zone community. The intent of this memo is, to the extent possible, to document existing practice and provide a means to ease succession of the database maintainers. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6557.
Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. RFC4833]. Time zone names can appear in the TZID field of calendaring VEVENTs [RFC5545]. The normative reference for these values is the TZ Database [TZDB]. From the early 1980s through 2011, that database, which has been in use on nearly all UNIX systems, Java systems, and other sorts of systems, was hosted at the U.S. National Institutes of Health (NIH). The database consists of both historic and current entries for geographies throughout the world. Associated with the database is a reference implementation of ISO/IEC 9899 C [ISO9899C] and IEEE 1003.1 [IEEE1003.1] POSIX time functions that can be used to convert time values. The database was previously maintained by volunteers who participated in the <email@example.com> mailing list that was also hosted at the NIH. The database itself is updated approximately twenty times per year, depending on the year, based on information these experts provide to the maintainer. Arthur David Olson has maintained the database, coordinated the mailing list, and provided a release platform since the database's inception. With his retirement now approaching, it is necessary to provide a means for this good work to continue. The time zone community has requested that the IETF adopt the ongoing maintenance of the Time Zone Database. The time zone community would like the IETF to maintain it in a consistent fashion to its administration of the Internet protocol parameters and values.
RFC2119]. IANA (Internet Assigned Numbers Authority): For purposes of this RFC, IANA is a role, not an organization. The IANA Considerations defined in this RFC will be provided by the Internet Corporation for Assigned Names and Numbers (ICANN) in accordance with the IETF-ICANN "Memorandum of Understanding Concerning Technical Work of the Internet Assigned Numbers Authority", which was signed and ratified in March of 2000[RFC2860]. TZ Database: The Time Zone Database, sometimes referred to as the "Olson Database". This database consists of information about offsets from UTC for different localities, including daylight saving time (DST) transition information. TZ Coordinator: The person or people who maintain and manage release of the TZ Database. The TZ Coordinator also has responsibility for managing the TZ mailing list. The TZ Coordinator is an IANA Designated Expert, as defined in Section 3.2 of [RFC5226], except as regards to appeals, as discussed in Section 5 of this document. Roughly speaking, this means that the IESG will choose one or more experts to manage the TZ database, code, and mailing list. The TZ Coordinator will also lead work to develop appropriate service metrics. There SHALL be a single lead individual and at least one backup individual for this function. TZ mailing list: The forum where matters relating to the TZ database and supporting code are discussed. The rest of this document specifies the following: 1. Transferring and maintenance of the TZ mailing list; 2. Procedures for selecting a technical expert who will play the role of TZ Coordinator and release manager for the TZ database; 3. Procedures for updating the TZ database; 4. Maintenance and ownership of reference code; and 5. Ownership of the database.
https://mm.icann.org/mailman/listinfo/tz/>. The TZ Coordinator will continue to manage the list. While the TZ Coordinator may establish other rules of governance for the list, members of that list will be informed that a condition of participating on the list is that all contributions to the list are released to the public domain, and that by placing their contribution in the public domain, contributors waive forever any intellectual property claims. The list will be used just as it has been: to learn of, discuss, and confirm TZ definition changes, as well as to serve as an announcement list for new versions of the database. http://www.iana.org/time-zones>. The criteria for updates to the database include the following: 1. New TZ names (e.g., locations) are only to be created when the scope of the region a name was envisioned to cover is no longer accurate.
2. In order to correct historical inaccuracies, a new TZ name MAY be added when it is necessary to indicate what was the consensus view at a given time and location. Such TZ names are usually not added when the inaccuracy was prior to 1970. 3. Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry. To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was.
1. Attempt to resolve the concern directly with the TZ Coordinator. 2. If a resolution cannot be reached directly with the TZ Coordinator, express the concern to the community and attempt to achieve rough consensus regarding a resolution on the TZ mailing list. The Area Directors of the IETF Applications Area may at their discretion attempt to guide the members of the community to rough consensus. 3. As a last resort, if a resolution cannot be reached on the TZ mailing list, appeal to the IESG for a resolution. The appellant must show that the decision made by the TZ Coordinator (a) was materially in error and (b) has caused material harm. In its deliberations regarding an appeal, the IESG shall weigh all the evidence presented to it and use its best judgment in determining a resolution. RFC5378] and 79 [RFC3979] do not apply to the TZ Database or contributions that individuals make to it. Should any claims be made and substantiated against the TZ Database, the organization that is providing the IANA Considerations defined in this RFC, under the memorandum of understanding with the IETF, currently ICANN, may act in accordance with all competent court orders. No ownership claims will be made by ICANN or the IETF Trust on the database or the code. Any person making a contribution to the database or code waives all rights to future claims in that contribution or in the TZ Database.
o Maintenance of a repository for the TZ database and associated reference code. The TZ Coordinator SHALL be named by the IESG as described above, and will act as the maintainer of the database and code, as described above. o Creation of appropriate access for the TZ Coordinator to maintain the database, as well as necessary tooling that may be required, so long as no direct software costs are incurred. o Establishment of security of the system upon which the database resides. Both current and historical versions of the database will be stored and distributed via HTTP/HTTPS. o Maintenance of a cryptographic private key that is used to sign the database and that will survive a change of TZ Coordinator. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [TZDB] Eggert, P. and A. Olson, "Sources for Time Zone and Daylight Saving Time Data", 1987, <ftp://ftp.iana.org/tz/code/tz-link.htm>. [IEEE1003.1] Institute of Electrical and Electronics Engineers, "Standard for Information Technology - Portable Operating System Interface (POSIX) - Base Definitions", IEEE Standard 1003.1-2008, December 2008. [ISO9899C] International Standards Organization, "Information technology -- Programming languages -- C", ISO/ IEC Standard 9899:2011, December 2011. [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 4833, April 2007. [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.