RFC 6557

RFC 6557: Procedures for Maintaining the Time Zone Database 🌸

Okay bestie, this is RFC 6557 💖, a Best Current Practice (it's BCP 175 ✨) from February 2012 🎀. It came from the Internet Engineering Task Force (IETF) and it's written by E. Lear of Cisco Systems GmbH and P. Eggert of UCLA. Its ISSN is 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates, so there's nothing to chase there 🧚

Abstract

Okay so, time zone info is a basic protocol element in protocols like the calendaring suite and DHCP 📅. The Time Zone (TZ) Database lists the indices those protocols use, plus what they actually mean, for every locality in the world 🌍. A group of volunteers has meticulously maintained it and shared it free of charge, coordinated by one single volunteer who is now planning to retire 😭. This memo lays out the procedures for maintaining the TZ database and its associated code: how to submit proposed updates, how decisions about including those updates get made, and how a designated expert gets picked by and for the time zone community 💅. The goal is to write down existing practice as much as possible and make it easier for the maintainers to pass the torch 🔥.

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 it has been approved for publication by the Internet Engineering Steering Group (IESG) ✨. Further info on BCPs is in Section 2 of RFC 5741 💜.

Info about the current status of this document, any errata, and how to give feedback on it is 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) as they stand on the date this document was published. Please read these carefully, because they spell out 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 they come without warranty as described in the Simplified BSD License 💀.

1. Introduction 🦋

The IETF has specified several standards that make use of time zone information. DHCP uses time zone names to configure devices with the correct local time [RFC4833] 🕰️. Time zone names can also show up in the TZID field of calendaring VEVENTs [RFC5545] 📆. The normative reference for these values is the TZ Database [TZDB], full stop, no debate 💅. From the early 1980s through 2011, that database was hosted at the U.S. National Institutes of Health (NIH). It has been in use on nearly all UNIX systems, Java systems, and other sorts of systems, and it has both historic and current entries for geographies all over the world 🌏. It also comes with a reference implementation of ISO/IEC 9899 C [ISO9899C] and IEEE 1003.1 [IEEE1003.1] POSIX time functions that you can use to convert time values ✨.

The database was previously maintained by volunteers who took part in the <tz@elsie.nci.nih.gov> mailing list, which was also hosted at the NIH 📬. The database itself gets updated roughly twenty times a year, depending on the year, based on info those experts send to the maintainer 🗓️. Arthur David Olson has maintained the database, coordinated the mailing list, and provided a release platform since the database's very beginning 👑. With his retirement now approaching, we need a way to keep this amazing work going 🥺.

The time zone community has asked the IETF to take on the ongoing maintenance of the Time Zone Database 🫶. They'd like the IETF to maintain it in a consistent way with how it administers the Internet protocol parameters and values 🍓.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [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) under 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 called the "Olson Database" 🌸. It holds info about offsets from UTC for different localities, including daylight saving time (DST) transition info ⏰.
• TZ Coordinator: The person or people who maintain and manage the release of the TZ Database 👩‍💻. The TZ Coordinator also runs the TZ mailing list 💌. The TZ Coordinator is an IANA Designated Expert, as defined in Section 3.2 of [RFC5226], except when it comes to appeals, which are covered in Section 5 of this document ⚖️. Roughly speaking, this means the IESG will choose one or more experts to manage the TZ database, code, and mailing list 🧠. The TZ Coordinator will also lead the 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 about the TZ database and its supporting code get 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.

2. The TZ Mailing List 📬

For many years, the TZ mailing list has been the place where people discussed changes to the TZ database and its support files 🗨️. The list is also used to announce releases of the database 📣. Right now, the TZ mailing list is administered by the TZ Coordinator 💅.

The list membership has moved from the NIH to the IANA mail server 🚚. Going forward, its address is <tz@iana.org> 💌. You can subscribe at <https://mm.icann.org/mailman/listinfo/tz/> 🎀. The TZ Coordinator will keep managing the list ✨. The TZ Coordinator may set up other rules of governance for the list, but members will be told that a condition of joining the list is that every contribution to it is released to the public domain 🌈. By putting a contribution in the public domain, contributors waive forever any intellectual property claims 🫶.

The list will keep working just like it always has: to learn about, discuss, and confirm TZ definition changes, and to serve as an announcement list for new versions of the database 🦋.

3. Making Updates to the TZ Database 🛠️

Updates to the TZ database are made by the TZ Coordinator in consultation with the TZ mailing list 💬. The TZ Coordinator has the power, as the designated expert, to decide on appropriate changes, but SHOULD take into account the views expressed on the mailing list 👂.

The TZ Coordinator also decides the timing of database releases ⏱️. Right now, a release is several archive files that get downloaded from a well-known location 📦.

Going forward, the TZ database, supporting code, and any appropriate supporting information SHOULD be cryptographically signed before release, using well known public keys, and then distributed from <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. Instead, they use judgment and whatever sources are available to figure out what the average person on the street would think the time actually is, or, for historical corrections, what it was 🕰️.

4. Selecting or Replacing a TZ Coordinator 👑

Every so often, it'll be necessary to appoint a new TZ Coordinator 🔄. This could happen for a few reasons:

• The TZ Coordinator is retiring (as Arthur David Olson is) or has announced that he or she will be unable to continue to perform the function 👋;
• The TZ Coordinator is missing, has become incapacitated, or has died 💔; or
• The TZ Coordinator is not performing the function in accordance with community wishes 🤨.

In any of these cases, members of the community should raise the issue on the TZ mailing list and try to reach consensus on a new candidate for the TZ Coordinator role 🗳️. If rough consensus can't be reached easily, the Area Directors of the IETF Applications Area should try to guide the community to rough consensus 🧭. The candidate that the community agrees on through rough consensus shall be presented to the IESG for confirmation ✅. If rough consensus still can't be reached, even with guidance from the Applications Area Directors, the IESG shall use whatever means it has at its disposal to choose a candidate who, in its best judgment, will be able to fulfill the role of TZ Coordinator 😤.

5. Appealing Database Decisions ⚖️

The TZ Coordinator makes decisions based on expertise, and with guidance from the TZ mailing list 🧠. If a member of the community has a concern about an individual decision the TZ Coordinator made regarding the TZ database, that person shall proceed as follows 📝:

1. Try to resolve the concern directly with the TZ Coordinator 🤝.
2. If a resolution can't be reached directly with the TZ Coordinator, bring the concern to the community and try to achieve rough consensus on a resolution on the TZ mailing list 📣. The Area Directors of the IETF Applications Area may, at their discretion, try to guide the community to rough consensus 🧭.
3. As a last resort, if a resolution can't 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 about an appeal, the IESG shall weigh all the evidence presented to it and use its best judgment in determining a resolution ⚖️.

Part 2 is coming up next, with the rest of this RFC 🎀💅

6. Maintenance and Distribution of Reference Code ✨

Okay so the maintainer of the TZ database also looks after the reference code 🛠️, and most of it is public domain 🌈. The reference implementation shall be distributed along with a cryptographic signature that you can check with a public key 🔐. A few files from this software come with licenses 📜, and where those exist, the licenses SHALL NOT be changed 🙅‍♀️. Protect those licenses bestie!!

7. Database Ownership 👑

The TZ database is not an IETF Contribution or an IETF document 🙅‍♀️. It's a work that already existed, gets updated all the time, is in the public domain, and is meant to stay that way 🌸. So BCPs 78 [RFC5378] and 79 [RFC3979] don't apply to the TZ Database or to the stuff individuals contribute to it 💅. If any claims get made and actually backed up against the TZ Database, the organization providing the IANA Considerations in this RFC (under the memorandum of understanding with the IETF, which is currently ICANN) may act in accordance with all competent court orders ⚖️. ICANN and the IETF Trust won't make any ownership claims on the database or the code 💖. And anyone who makes a contribution to the database or code waives all rights to future claims in that contribution or in the TZ Database 🫶. Iconic behaviour, honestly 😭.

8. IANA Considerations 🎀

This section covers the following IANA actions, and I'm obsessed with how organized it is 🧚:

• Assistance on request of the IESG in selection of the TZ Coordinator, based on the procedures set forth above.
• 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.
• 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.
• 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.
• Maintenance of a cryptographic private key that is used to sign the database and that will survive a change of TZ Coordinator.

9. Security Considerations 🚨

😱 Okay this one is serious, bestie. The distribution of the database is currently not secured. This memo states that the TZ database SHOULD be distributed with a valid cryptographic signature moving forward. Please take this one seriously 🙏

10. Acknowledgments 🫶

The authors want to thank the TZ mailing list for their remarkable achievements over the years 🥹. Big thanks also to Marshall Eubanks, S. Moonesamy, Peter Saint-Andre, Alexey Melenkov, Tony Finch, Elwyn Davies, Alfred Hoenes, Ted Hardie, Barry Leiba, Russ Housley, Pete Resnick, and Elise Gerich for all the improvements they made to this document 💜. A super special shout-out goes to Arthur David Olson for his excellent stewardship 👑, to Rob Elz for continuing that stewardship 🌟, and to the team at ICANN for their good efforts, moving forward 🦋.

11. References 📚

11.1. Normative References

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

11.2. Informational References 🧠

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

Authors' Addresses 💌

Eliot Lear
Cisco Systems GmbH
Richtistrasse 7
CH-8304  Wallisellen
Switzerland

Phone: +41 1 878 9200
EMail: lear@cisco.com


Paul Eggert
UCLA
Computer Science Department
4532J Boelter Hall
Los Angeles, CA  90095
USA

Phone: +1 310 267 2254
EMail: eggert@cs.ucla.edu