Internet Engineering Task Force (IETF) M. Douglass
Request for Comments: 7808 Spherical Cow Group
Category: Standards Track C. Daboo
ISSN: 2070-1721 Apple
March 2016
Internet Engineering Task Force (IETF) M. Douglass
Request for Comments: 7808 Spherical Cow Group
Category: Standards Track C. Daboo
ISSN: 2070-1721 Apple
March 2016
Time Zone Data Distribution Service
时区数据分发服务
Abstract
摘要
This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.
本文档定义了时区数据分发服务，该服务允许向客户端系统（如日历和调度应用程序或操作系统）可靠、安全、快速地传递时区数据和闰秒规则。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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/rfc7808.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7808.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3. General Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Time Zone . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Time Zone Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. Time Zone Metadata . . . . . . . . . . . . . . . . . . . 7
3.4. Time Zone Data Server . . . . . . . . . . . . . . . . . . 7
3.5. Observance . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Time Zone Identifiers . . . . . . . . . . . . . . . . . . 7
3.7. Time Zone Aliases . . . . . . . . . . . . . . . . . . . . 8
3.8. Time Zone Localized Names . . . . . . . . . . . . . . . . 8
3.9. Truncating Time Zones . . . . . . . . . . . . . . . . . . 9
3.10. Time Zone Versions . . . . . . . . . . . . . . . . . . . 10
4. Time Zone Data Distribution Service Protocol . . . . . . . . 10
4.1. Server Protocol . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Time Zone Queries . . . . . . . . . . . . . . . . . . 11
4.1.2. Time Zone Formats . . . . . . . . . . . . . . . . . . 11
4.1.3. Time Zone Localization . . . . . . . . . . . . . . . 12
4.1.4. Conditional Time Zone Requests . . . . . . . . . . . 12
4.1.5. Expanded Time Zone Data . . . . . . . . . . . . . . . 14
4.1.6. Server Requirements . . . . . . . . . . . . . . . . . 14
4.1.7. Error Responses . . . . . . . . . . . . . . . . . . . 14
4.1.8. Extensions . . . . . . . . . . . . . . . . . . . . . 14
4.2. Client Guidelines . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.1. SRV Service Labels for the Time Zone Data
Distribution Service . . . . . . . . . . . . . . 15
4.2.1.2. TXT Records for a Time Zone Data Distribution
Service . . . . . . . . . . . . . . . . . . . . . 15
4.2.1.3. Well-Known URI for a Time Zone Data Distribution
Service . . . . . . . . . . . . . . . . . . . . . 16
4.2.1.3.1. Example: Well-Known URI Redirects to Actual
Context Path . . . . . . . . . . . . . . . . 17
4.2.2. Synchronization of Time Zones . . . . . . . . . . . . 17
4.2.2.1. Initial Synchronization of All Time Zones . . . . 17
4.2.2.2. Subsequent Synchronization of All Time Zones . . 17
4.2.2.3. Synchronization with Preexisting Time Zone Data . 18
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. "capabilities" Action . . . . . . . . . . . . . . . . . . 18
5.1.1. Example: get capabilities . . . . . . . . . . . . . . 19
5.2. "list" Action . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Example: List Time Zone Identifiers . . . . . . . . . 22
5.3. "get" Action . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Example: Get Time Zone Data . . . . . . . . . . . . . 24
5.3.2. Example: Conditional Get Time Zone Data . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3. General Considerations . . . . . . . . . . . . . . . . . . . 7
3.1. Time Zone . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Time Zone Data . . . . . . . . . . . . . . . . . . . . . 7
3.3. Time Zone Metadata . . . . . . . . . . . . . . . . . . . 7
3.4. Time Zone Data Server . . . . . . . . . . . . . . . . . . 7
3.5. Observance . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Time Zone Identifiers . . . . . . . . . . . . . . . . . . 7
3.7. Time Zone Aliases . . . . . . . . . . . . . . . . . . . . 8
3.8. Time Zone Localized Names . . . . . . . . . . . . . . . . 8
3.9. Truncating Time Zones . . . . . . . . . . . . . . . . . . 9
3.10. Time Zone Versions . . . . . . . . . . . . . . . . . . . 10
4. Time Zone Data Distribution Service Protocol . . . . . . . . 10
4.1. Server Protocol . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Time Zone Queries . . . . . . . . . . . . . . . . . . 11
4.1.2. Time Zone Formats . . . . . . . . . . . . . . . . . . 11
4.1.3. Time Zone Localization . . . . . . . . . . . . . . . 12
4.1.4. Conditional Time Zone Requests . . . . . . . . . . . 12
4.1.5. Expanded Time Zone Data . . . . . . . . . . . . . . . 14
4.1.6. Server Requirements . . . . . . . . . . . . . . . . . 14
4.1.7. Error Responses . . . . . . . . . . . . . . . . . . . 14
4.1.8. Extensions . . . . . . . . . . . . . . . . . . . . . 14
4.2. Client Guidelines . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1.1. SRV Service Labels for the Time Zone Data
Distribution Service . . . . . . . . . . . . . . 15
4.2.1.2. TXT Records for a Time Zone Data Distribution
Service . . . . . . . . . . . . . . . . . . . . . 15
4.2.1.3. Well-Known URI for a Time Zone Data Distribution
Service . . . . . . . . . . . . . . . . . . . . . 16
4.2.1.3.1. Example: Well-Known URI Redirects to Actual
Context Path . . . . . . . . . . . . . . . . 17
4.2.2. Synchronization of Time Zones . . . . . . . . . . . . 17
4.2.2.1. Initial Synchronization of All Time Zones . . . . 17
4.2.2.2. Subsequent Synchronization of All Time Zones . . 17
4.2.2.3. Synchronization with Preexisting Time Zone Data . 18
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. "capabilities" Action . . . . . . . . . . . . . . . . . . 18
5.1.1. Example: get capabilities . . . . . . . . . . . . . . 19
5.2. "list" Action . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Example: List Time Zone Identifiers . . . . . . . . . 22
5.3. "get" Action . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Example: Get Time Zone Data . . . . . . . . . . . . . 24
5.3.2. Example: Conditional Get Time Zone Data . . . . . . . 25
5.3.3. Example: Get Time Zone Data Using a Time Zone Alias . 25
5.3.4. Example: Get Truncated Time Zone Data . . . . . . . . 26
5.3.5. Example: Request for a Nonexistent Time Zone . . . . 27
5.4. "expand" Action . . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Example: Expanded JSON Data Format . . . . . . . . . 29
5.5. "find" Action . . . . . . . . . . . . . . . . . . . . . . 30
5.5.1. Example: find action . . . . . . . . . . . . . . . . 31
5.6. "leapseconds" Action . . . . . . . . . . . . . . . . . . 32
5.6.1. Example: Get Leap-Second Information . . . . . . . . 33
6. JSON Definitions . . . . . . . . . . . . . . . . . . . . . . 34
6.1. capabilities Action Response . . . . . . . . . . . . . . 34
6.2. list/find Action Response . . . . . . . . . . . . . . . . 37
6.3. expand Action Response . . . . . . . . . . . . . . . . . 38
6.4. leapseconds Action Response . . . . . . . . . . . . . . . 39
7. New iCalendar Properties . . . . . . . . . . . . . . . . . . 40
7.1. Time Zone Upper Bound . . . . . . . . . . . . . . . . . . 40
7.2. Time Zone Identifier Alias Property . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.1. Service Actions Registration . . . . . . . . . . . . . . 45
10.1.1. Service Actions Registration Procedure . . . . . . . 45
10.1.2. Registration Template for Actions . . . . . . . . . 46
10.1.3. Actions Registry . . . . . . . . . . . . . . . . . . 47
10.2. timezone Well-Known URI Registration . . . . . . . . . . 47
10.3. Service Name Registrations . . . . . . . . . . . . . . . 47
10.3.1. timezone Service Name Registration . . . . . . . . . 47
10.3.2. timezones Service Name Registration . . . . . . . . 48
10.4. TZDIST Identifiers Registry . . . . . . . . . . . . . . 48
10.4.1. Registration of invalid-action Error URN . . . . . . 49
10.4.2. Registration of invalid-changedsince Error URN . . . 49
10.4.3. Registration of tzid-not-found Error URN . . . . . . 50
10.4.4. Registration of invalid-format Error URN . . . . . . 50
10.4.5. Registration of invalid-start Error URN . . . . . . 50
10.4.6. Registration of invalid-end Error URN . . . . . . . 51
10.4.7. Registration of invalid-pattern Error URN . . . . . 51
10.5. iCalendar Property Registrations . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Normative References . . . . . . . . . . . . . . . . . . 52
11.2. Informative References . . . . . . . . . . . . . . . . . 55
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.3. Example: Get Time Zone Data Using a Time Zone Alias . 25
5.3.4. Example: Get Truncated Time Zone Data . . . . . . . . 26
5.3.5. Example: Request for a Nonexistent Time Zone . . . . 27
5.4. "expand" Action . . . . . . . . . . . . . . . . . . . . . 27
5.4.1. Example: Expanded JSON Data Format . . . . . . . . . 29
5.5. "find" Action . . . . . . . . . . . . . . . . . . . . . . 30
5.5.1. Example: find action . . . . . . . . . . . . . . . . 31
5.6. "leapseconds" Action . . . . . . . . . . . . . . . . . . 32
5.6.1. Example: Get Leap-Second Information . . . . . . . . 33
6. JSON Definitions . . . . . . . . . . . . . . . . . . . . . . 34
6.1. capabilities Action Response . . . . . . . . . . . . . . 34
6.2. list/find Action Response . . . . . . . . . . . . . . . . 37
6.3. expand Action Response . . . . . . . . . . . . . . . . . 38
6.4. leapseconds Action Response . . . . . . . . . . . . . . . 39
7. New iCalendar Properties . . . . . . . . . . . . . . . . . . 40
7.1. Time Zone Upper Bound . . . . . . . . . . . . . . . . . . 40
7.2. Time Zone Identifier Alias Property . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.1. Service Actions Registration . . . . . . . . . . . . . . 45
10.1.1. Service Actions Registration Procedure . . . . . . . 45
10.1.2. Registration Template for Actions . . . . . . . . . 46
10.1.3. Actions Registry . . . . . . . . . . . . . . . . . . 47
10.2. timezone Well-Known URI Registration . . . . . . . . . . 47
10.3. Service Name Registrations . . . . . . . . . . . . . . . 47
10.3.1. timezone Service Name Registration . . . . . . . . . 47
10.3.2. timezones Service Name Registration . . . . . . . . 48
10.4. TZDIST Identifiers Registry . . . . . . . . . . . . . . 48
10.4.1. Registration of invalid-action Error URN . . . . . . 49
10.4.2. Registration of invalid-changedsince Error URN . . . 49
10.4.3. Registration of tzid-not-found Error URN . . . . . . 50
10.4.4. Registration of invalid-format Error URN . . . . . . 50
10.4.5. Registration of invalid-start Error URN . . . . . . 50
10.4.6. Registration of invalid-end Error URN . . . . . . . 51
10.4.7. Registration of invalid-pattern Error URN . . . . . 51
10.5. iCalendar Property Registrations . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Normative References . . . . . . . . . . . . . . . . . . 52
11.2. Informative References . . . . . . . . . . . . . . . . . 55
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
Time zone data typically combines a coordinated universal time (UTC) offset with daylight saving time (DST) rules. Time zones are typically tied to specific geographic and geopolitical regions. Whilst the UTC offset for particular regions changes infrequently, DST rules can change frequently and sometimes with very little notice (maybe hours before a change comes into effect).
时区数据通常将协调世界时（UTC）偏移与夏令时（DST）规则相结合。时区通常与特定的地理和地缘政治区域相联系。虽然特定地区的UTC偏移量变化不频繁，但DST规则可能会频繁变化，有时几乎不需要通知（可能在变化生效前数小时）。
Calendaring and scheduling systems, such as those that use iCalendar [RFC5545], as well as operating systems, critically rely on time zone data to determine the correct local time. As such, they need to be kept up to date with changes to time zone data. To date, there has been no fast and easy way to do that. Time zone data is often supplied in the form of a set of data files that have to be "compiled" into a suitable database format for use by the client application or operating system. In the case of operating systems, often those changes only get propagated to client machines when there is an operating system update, which can be infrequent, resulting in inaccurate time zone data being present for significant amounts of time. In some cases, old versions of operating systems stop being supported, but are still in use and thus require users to manually "patch" their system to keep up to date with time zone changes.
日历和日程安排系统，如使用iCalendar[RFC5545]的系统以及操作系统，严重依赖时区数据来确定正确的本地时间。因此，它们需要随着时区数据的变化而保持最新。到目前为止，还没有一种快速简便的方法可以做到这一点。时区数据通常以一组数据文件的形式提供，这些文件必须“编译”成适当的数据库格式，以供客户端应用程序或操作系统使用。在操作系统的情况下，通常只有在操作系统更新不频繁时，这些更改才会传播到客户端计算机，从而导致在相当长的时间内存在不准确的时区数据。在某些情况下，旧版本的操作系统不再受支持，但仍在使用中，因此需要用户手动“修补”其系统以跟上时区的变化。
Along with time zone data, it is also important to track the use of leap seconds to allow a mapping between International Atomic Time (TAI) and UTC. Leap seconds can be added (or possibly removed) at various times of year in an irregular pattern typically determined by precise astronomical observations. The insertion of leap seconds into UTC is currently the responsibility of the International Earth Rotation Service.
除了时区数据外，还必须跟踪闰秒的使用情况，以便在国际原子时（TAI）和UTC之间进行映射。闰秒可以在一年中的不同时间以一种不规则的模式增加（或可能减少），通常由精确的天文观测确定。国际地球自转服务机构目前负责在UTC中插入闰秒。
This specification defines a time zone data distribution service protocol that allows for fast, reliable, and accurate delivery of time zone data and leap-second information to client systems. This protocol is based on HTTP [RFC7230] using a simple JSON-based API [RFC7159].
本规范定义了时区数据分发服务协议，该协议允许向客户端系统快速、可靠和准确地传送时区数据和闰秒信息。该协议基于HTTP[RFC7230]，使用一个简单的基于JSON的API[RFC7159]。
This specification does not define the source of the time zone data or leap-second information. It is assumed that a reliable and accurate source is available. One such source is the IANA-hosted time zone database [RFC6557].
本规范未定义时区数据或闰秒信息的来源。假设有可靠和准确的来源。其中一个来源是IANA托管的时区数据库[RFC6557]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Unless otherwise indicated, UTC date-time values as specified in [RFC3339] use a "Z" suffix, and not fixed numeric offsets.
除非另有说明，否则[RFC3339]中规定的UTC日期时间值使用“Z”后缀，而不是固定的数字偏移。
This specification contains examples of HTTP requests and responses. In some cases, additional line breaks have been introduced into the request or response data to match maximum line-length limits of this document.
本规范包含HTTP请求和响应的示例。在某些情况下，请求或响应数据中引入了额外的换行符，以匹配本文档的最大行长度限制。
The overall process for the delivery of time zone data can be visualized via the diagram below.
时区数据交付的整个过程可以通过下图可视化。
==================== ====================
(a) | Contributors | | Contributors |
==================== ====================
| |
==================== ====================
(b) | Publisher A | | Publisher B |
==================== ====================
\ /
====================
(c) | Root Provider |
====================
/ | \
/ | \
====================== | ======================
(d) | Secondary Provider | | | Secondary Provider |
====================== | ======================
| | | |
| | | |
========== ========== ========== ==========
(e) | Client | | Client | | Client | | Client |
========== ========== ========== ==========
==================== ====================
(a) | Contributors | | Contributors |
==================== ====================
| |
==================== ====================
(b) | Publisher A | | Publisher B |
==================== ====================
\ /
====================
(c) | Root Provider |
====================
/ | \
/ | \
====================== | ======================
(d) | Secondary Provider | | | Secondary Provider |
====================== | ======================
| | | |
| | | |
========== ========== ========== ==========
(e) | Client | | Client | | Client | | Client |
========== ========== ========== ==========
Figure 1: Time Zone Data Distribution Service Architecture
图1：时区数据分发服务体系结构
The overall service is made up of several layers:
整个服务由几个层组成：
(a) Contributors: Individuals, governments, or organizations that provide information about time zones to the publishing process. There can be many contributors. Note this specification does not address how contributions are made.
(a) 贡献者：向发布过程提供时区信息的个人、政府或组织。可以有很多贡献者。注：本规范不涉及如何作出贡献。
(b) Publishers: Publishers aggregate information from contributors, determine the reliability of the information and, based on that, generate time zone data. There can be many publishers, each getting information from many different contributors. In some cases, a publisher may choose to "republish" data from another publisher.
(b) 发布者：发布者聚合贡献者的信息，确定信息的可靠性，并在此基础上生成时区数据。可以有许多出版商，每个出版商从许多不同的贡献者那里获得信息。在某些情况下，发布者可能会选择从其他发布者“重新发布”数据。
(c) Root Providers: Servers that obtain and then provide the time zone data from publishers and make that available to other servers or clients. There can be many root providers. Root providers can choose to supply time zone data from one or more publishers.
(c) 根提供程序：从发布服务器获取时区数据并提供给其他服务器或客户端的服务器。可以有许多根提供程序。根提供者可以选择从一个或多个发布者提供时区数据。
(d) Secondary Providers: Servers that handle the bulk of the requests and reduce the load on root servers. These will typically be simple, caches of the root server, located closer to clients. For example a large Internet Service Provider (ISP) may choose to set up their own secondary provider to allow clients within their network to make requests of that server rather than make requests of servers outside their network. Secondary servers will cache and periodically refresh data from the root servers.
(d) 辅助提供者：处理大量请求并减少根服务器负载的服务器。这些通常是根服务器的简单缓存，位于客户端附近。例如，大型Internet服务提供商（ISP）可能会选择建立自己的辅助提供商，以允许其网络内的客户端向该服务器发出请求，而不是向其网络外的服务器发出请求。辅助服务器将缓存并定期刷新根服务器中的数据。
(e) Clients: Applications, operating systems, etc., that make use of time zone data and retrieve that from either root or secondary providers.
(e) 客户端：应用程序、操作系统等，它们利用时区数据并从根提供者或辅助提供者检索时区数据。
Some of those layers may be coalesced by implementors. For example, a vendor may choose to implement the entire service as a single monolithic virtual server with the address embedded in distributed systems. Others may choose to provide a service consisting of multiple layers of providers, many secondary servers, and a small number of root servers.
其中一些层可以由实现者合并。例如，供应商可以选择将整个服务实现为单个单片虚拟服务器，地址嵌入到分布式系统中。其他人可能会选择提供由多层提供者、许多辅助服务器和少量根服务器组成的服务。
This specification is concerned only with the protocol used to exchange data between providers and from provider to client. This specification does not define how contributors pass their information to publishers, nor how those publishers vet that information to obtain trustworthy data, nor the format of the data produced by the publishers.
本规范仅涉及用于在提供者之间以及提供者与客户端之间交换数据的协议。本规范未定义贡献者如何将其信息传递给发布者，也未定义发布者如何审查该信息以获得可信数据，也未定义发布者生成的数据格式。
This section defines several terms and explains some key concepts used in this specification.
本节定义了几个术语，并解释了本规范中使用的一些关键概念。
A time zone is a description of the past and predicted future timekeeping practices of a collection of clocks that are intended to agree.
时区是对一组时钟的过去和预测的未来计时实践的描述，这些时钟旨在达成一致。
Note that the term "time zone" does not have the common meaning of a region of the world at a specific UTC offset, possibly modified by daylight saving time. For example, the "Central European Time" zone can correspond to several time zones "Europe/Berlin", "Europe/Paris", etc., because subregions have kept time differently in the past.
请注意，“时区”一词并不具有特定UTC偏移量（可能由夏令时修改）下的世界区域的通用含义。例如，“中欧时区”可以对应于“欧洲/柏林”、“欧洲/巴黎”等几个时区，因为各次区域过去的计时方式不同。
Time zone data is data that defines a single time zone, including an identifier, UTC offset values, DST rules, and other information such as time zone abbreviations.
时区数据是定义单个时区的数据，包括标识符、UTC偏移值、DST规则和其他信息，如时区缩写。
Time zone metadata is data that describes additional properties of a time zone that is not itself included in the time zone data. This can include such things as the publisher name, version identifier, aliases, and localized names (see below).
时区元数据是描述时区的附加属性的数据，该时区本身不包括在时区数据中。这可能包括发布者名称、版本标识符、别名和本地化名称（见下文）。
A time zone data server is a server implementing the Time Zone Data Distribution Service Protocol defined by this specification.
时区数据服务器是实现本规范定义的时区数据分发服务协议的服务器。
A time zone with varying rules for the UTC offset will have adjacent periods of time that use different UTC offsets. Each period of time with a constant UTC offset is called an observance.
具有不同UTC偏移规则的时区将具有使用不同UTC偏移的相邻时段。具有恒定UTC偏移量的每个时间段称为观测。
Time zone identifiers are unique names associated with each time zone, as defined by publishers. The iCalendar [RFC5545] specification has a "TZID" property and parameter whose value is set to the corresponding time zone identifier and used to identify time zone data and relate time zones to start and end dates in events,
时区标识符是由发布者定义的与每个时区关联的唯一名称。iCalendar[RFC5545]规范具有一个“TZID”属性和参数，其值设置为相应的时区标识符，用于标识时区数据，并将时区与事件中的开始和结束日期关联，
etc. This specification does not define what format of time zone identifiers should be used. It is possible that time zone identifiers from different publishers overlap, and there might be a need for a provider to distinguish those with some form of "namespace" prefix identifying the publisher. However, development of a standard (global) naming scheme for time zone identifiers is out of scope for this specification.
本规范未定义应使用的时区标识符格式。来自不同发布服务器的时区标识符可能重叠，提供者可能需要区分那些具有某种形式的“名称空间”前缀的标识符来标识发布服务器。然而，为时区标识符开发标准（全局）命名方案超出了本规范的范围。
Time zone aliases map a name onto a time zone identifier. For example, "US/Eastern" is usually mapped on to "America/New_York". Time zone aliases are typically used interchangeably with time zone identifiers when presenting information to users.
时区别名将名称映射到时区标识符上。例如，“美国/东部”通常映射到“美国/纽约”。当向用户呈现信息时，时区别名通常与时区标识符互换使用。
A time zone data distribution service needs to maintain time zone alias mapping information and expose that data to clients as well as allow clients to query for time zone data using aliases. When returning time zone data to a client, the server returns the data with an identifier matching the query, but it can include one or more additional identifiers in the data to provide a hint to the client that alternative identifiers are available. For example, a query for "US/Eastern" could include additional identifiers for "America/ New_York" or "America/Montreal".
时区数据分发服务需要维护时区别名映射信息，并向客户端公开该数据，以及允许客户端使用别名查询时区数据。当向客户机返回时区数据时，服务器返回具有与查询匹配的标识符的数据，但它可以在数据中包含一个或多个附加标识符，以向客户机提供提示，说明有其他标识符可用。例如，“美国/东部”的查询可以包括“美国/纽约”或“美国/蒙特利尔”的附加标识符。
The set of aliases may vary depending on whether time zone data is truncated (see Section 3.9). For example, a client located in the US state of Michigan may see "US/Eastern" as an alias for "America/ Detroit", whereas a client in the US state of New Jersey may see it as an alias for "America/New_York", and all three names may be aliases if time zones are truncated to post-2013 data.
根据时区数据是否被截断，别名集可能会有所不同（参见第3.9节）。例如，位于美国密歇根州的客户可能会将“US/Eastern”视为“America/Detroit”的别名，而位于美国新泽西州的客户可能会将其视为“America/New_York”的别名，如果时区被截断为2013年后的数据，则所有三个名称都可能是别名。
Localized names are names for time zones that can be presented to a user in their own language. Each time zone may have one or more localized names associated with it. Names would typically be unique in their own locale as they might be presented to the user in a list. Localized names are distinct from abbreviations commonly used for UTC offsets within a time zone. For example, the time zone "America/ New_York" may have the localized name "Nueva York" in a Spanish locale, as distinct from the abbreviations "EST" and "EDT", which may or may not have their own localizations.
本地化名称是时区的名称，可以用用户自己的语言呈现给用户。每个时区可能有一个或多个与其关联的本地化名称。名称在其自己的语言环境中通常是唯一的，因为它们可能在列表中呈现给用户。本地化名称不同于时区内UTC偏移常用的缩写。例如，时区“America/New_York”可能在西班牙语区域中具有本地化名称“Nueva York”，这与缩写“EST”和“EDT”不同，后者可能有也可能没有自己的本地化。
A time zone data distribution service might need to maintain localized name information, for one or more chosen languages, as well as allow clients to query for time zone data using localized names.
时区数据分发服务可能需要维护一种或多种选定语言的本地化名称信息，并允许客户端使用本地化名称查询时区数据。
Time zone data can contain information about past and future UTC offsets that may not be relevant for a particular server's intended clients. For example, calendaring and scheduling clients are likely most concerned with time zone data that covers a period for one or two years in the past on into the future, as users typically create new events only for the present and future. Similarly, time zone data might contain a large amount of "future" information about transitions occurring many decades into the future. Again, clients might be concerned only with a smaller range into the future, and data past that point might be unnecessary.
时区数据可以包含有关过去和未来UTC偏移量的信息，这些信息可能与特定服务器的预期客户端无关。例如，日历和日程安排客户端可能最关心的是从过去到未来一年或两年的时区数据，因为用户通常只为当前和未来创建新事件。类似地，时区数据可能包含大量关于几十年后发生的转变的“未来”信息。同样，客户可能只关心未来的较小范围，超过该范围的数据可能是不必要的。
To avoid having to send unnecessary data, servers can choose to truncate time zone data to a range determined by start- and end-point date-time values, and to provide only offsets and rules between those points. If such truncation is done, the server MUST include the ranges it is using in the "capabilities" action response (see Section 6.1), so that clients can take appropriate action if they need time zone data for times outside of those ranges.
为了避免发送不必要的数据，服务器可以选择将时区数据截断到由开始点和结束点日期时间值确定的范围内，并且只提供这些点之间的偏移量和规则。如果完成了此类截断，服务器必须在“功能”操作响应中包含它正在使用的范围（请参见第6.1节），这样，如果客户端需要这些范围以外时间的时区数据，就可以采取适当的操作。
The truncation points at the start and end of a range are always a UTC date-time value, with the start point being "inclusive" to the overall range, and the end point being "exclusive" to the overall range (i.e., the end value is just past the end of the last valid value in the range). A server will advertise a truncation range for the truncated data it can supply or will provide an indicator that it can truncate at any start or end point to produce arbitrary ranges. In addition, the server can advertise that it supplies untruncated data -- that is, data that covers the full range of times available from the source publisher. In the absence of any indication of truncated data available on the server, the server will supply only untruncated data.
范围起点和终点的截断点始终是UTC日期时间值，起点对整个范围是“包含的”，终点对整个范围是“独占的”（即，终点刚好超过范围中最后一个有效值的终点）。服务器将公布它可以提供的截断数据的截断范围，或者提供一个指示器，它可以在任何起点或终点截断以生成任意范围。此外，服务器还可以公布它提供了不受信任的数据，即覆盖源发布服务器提供的全部时间范围的数据。如果没有任何关于服务器上可用的截断数据的指示，服务器将只提供不受信任的数据。
When truncating the start of a "VTIMEZONE" component, the server MUST include exactly one "STANDARD" or "DAYLIGHT" subcomponent with a "DTSTART" property value that matches the start point of the truncation range, and appropriate "TZOFFSETFROM" and "TZOFFSETTO" properties to indicate the correct offset in effect right before and after the start point of the truncation range. This subcomponent, which is the first observance defined by the time zone data, represents the earliest valid date-time covered by the time zone data in the truncated "VTIMEZONE" component.
截断“VTIMEZONE”组件的开始时，服务器必须恰好包含一个“标准”或“日光”子组件，该子组件的“DTSTART”属性值与截断范围的开始点匹配，并包含相应的“TZOFFSETFROM”和“TZOFFSETTO”属性来指示截断范围起点前后有效的正确偏移。此子组件是时区数据定义的第一个遵守，表示被截断的“VTIMEZONE”组件中时区数据覆盖的最早有效日期时间。
When truncating the end of a "VTIMEZONE" component, the server MUST include a "TZUNTIL" iCalendar property (Section 7.1) in the "VTIMEZONE" component to indicate the end point of the truncation range.
截断“VTIMEZONE”组件的结尾时，服务器必须在“VTIMEZONE”组件中包含“TZUNTIL”iCalendar属性（第7.1节），以指示截断范围的终点。
Time zone data changes over time, and it is important for consumers of that data to stay up to date with the latest versions. As a result, it is useful to identify individual time zones with a specific version number or version identifier as supplied by the time zone data publisher. There are two common models that time zone data publishers might use to publish updates to time zone data:
时区数据会随着时间的推移而变化，对于数据的使用者来说，及时了解最新版本非常重要。因此，可以使用时区数据发布者提供的特定版本号或版本标识符来标识各个时区。时区数据发布者可以使用两种常见模型发布对时区数据的更新：
a. with the "monolithic" model, the data for all time zones is published in one go, with a single version number or identifier applied to the entire data set. For example, a publisher producing data several times a year might use version identifiers "2015a", "2015b", etc.
a. 在“单片”模型中，所有时区的数据一次发布，对整个数据集应用一个版本号或标识符。例如，每年多次生成数据的发布者可能会使用版本标识符“2015a”、“2015b”等。
b. with the "incremental" model, each time zone has its own version identifier, so that each time zone can be independently updated without impacting any others. For example, if the initial data has version "A.1" for time zone "A", and "B.1" for time zone "B", and then time zone "B" changes; when the data is next published, time zone "A" will still have version "A.1", but time zone "B" will now have "B.2".
b. 在“增量”模型中，每个时区都有自己的版本标识符，因此每个时区都可以独立更新，而不会影响任何其他时区。例如，如果初始数据的版本“A.1”表示时区“A”，版本“B.1”表示时区“B”，则时区“B”发生变化；下次公布数据时，时区“A”仍将有版本“A.1”，但时区“B”现在将有“B.2”。
A time zone data distribution service needs to ensure that the version identifiers used by the time zone data publisher are available to any client, along with the actual publisher name on a per-time-zone basis. This allows clients to compare publisher/ version details on any server, with existing locally cached client data, and only fetch those time zones that have actually changed (see Section 4.2.2 for more details on how clients synchronize data from the server).
时区数据分发服务需要确保时区数据发布者使用的版本标识符以及每个时区的实际发布者名称可供任何客户端使用。这允许客户端将任何服务器上的发布服务器/版本详细信息与现有本地缓存的客户端数据进行比较，并仅获取实际更改的时区（有关客户端如何从服务器同步数据的更多详细信息，请参阅第4.2.2节）。
The time zone data distribution service protocol uses HTTP [RFC7230] for query and delivery of time zone data, metadata, and leap-second information. The interactions with the HTTP server can be broken down into a set of "actions" that define the overall function being requested (see Section 5). Each action targets a specific HTTP resource using the GET method, with various request-URI parameters altering the behavior as needed.
时区数据分发服务协议使用HTTP[RFC7230]查询和传递时区数据、元数据和闰秒信息。与HTTP服务器的交互可以分解为一组“操作”，这些操作定义了所请求的整体功能（请参见第5节）。每个操作都使用GET方法以特定的HTTP资源为目标，并根据需要使用各种请求URI参数改变行为。
The HTTP resources used for requests will be identified via URI templates [RFC6570]. The overall time zone data distribution service has a "context path" request-URI template defined as "{/service-prefix}". This "root" prefix is discovered by the client as per
用于请求的HTTP资源将通过URI模板[RFC6570]进行标识。整个时区数据分发服务有一个定义为“{/service prefix}”的“上下文路径”请求URI模板。此“根”前缀由客户端根据查找
Section 4.2.1. Request-URIs that target time zone data directly use the prefix template "{/service-prefix,data-prefix}". The second component of the prefix template can be used to introduce additional path segments in the request-URI to allow for alternative ways to "partition" the time zone data. For example, time zone data might be partitioned by publisher release dates or version identifiers. This specification does not define any partitions; that is left for future extensions. When the "data-prefix" variable is empty, the server is expected to return the current version of time zone data it has for all publishers it supports.
第4.2.1节。直接使用前缀模板“{/service prefix，data prefix}”请求以时区数据为目标的URI。前缀模板的第二个组件可用于在请求URI中引入额外的路径段，以允许使用其他方法对时区数据进行“分区”。例如，时区数据可能按发布者发布日期或版本标识符进行分区。本规范未定义任何分区；这是留给未来扩展的。“data prefix”变量为空时，服务器应返回其支持的所有发布服务器的时区数据的当前版本。
All URI template variable values, and URI request parameters that contain text values, MUST be encoded using the UTF-8 [RFC3629] character set. All responses MUST return data using the UTF-8 [RFC3629] character set. It is important to note that any "/" characters, which are frequently found in time zone identifiers, are percent-encoded when used in the value of a path segment expansion variable in a URI template (as per Section 3.2.6 of [RFC6570]). Thus, the time zone identifier "America/New_York" would appear as "America%2FNew_York" when used as the value for the "{/tzid}" URI template variable defined later in this specification.
必须使用UTF-8[RFC3629]字符集对所有URI模板变量值和包含文本值的URI请求参数进行编码。所有响应必须使用UTF-8[RFC3629]字符集返回数据。需要注意的是，在URI模板中路径段扩展变量的值中使用时（根据[RFC6570]第3.2.6节），时区标识符中经常出现的任何“/”字符都是百分比编码的。因此，时区标识符“America/New_York”在用作本规范后面定义的“{/tzid}”URI模板变量的值时将显示为“America%2FNew_York”。
The server provides time zone metadata in the form of a JSON [RFC7159] object. Clients can directly request the time zone metadata or issue queries for subsets of metadata that match specific criteria.
服务器以JSON[RFC7159]对象的形式提供时区元数据。客户端可以直接请求时区元数据，也可以查询符合特定条件的元数据子集。
Security and privacy considerations for this protocol are discussed in detail in Sections 8 and 9, respectively.
第8节和第9节分别详细讨论了本协议的安全和隐私注意事项。
Time zone identifiers, aliases, or localized names can be used to query for time zone data or metadata. This will be more explicitly defined below for each action. In general, however, if a "tzid" URI template variable is used, then the value may be an identifier or an alias. When the "pattern" URI query parameter is used, it may be an identifier, an alias, or a localized name.
时区标识符、别名或本地化名称可用于查询时区数据或元数据。下面将为每个操作更明确地定义这一点。但是，通常，如果使用“tzid”URI模板变量，则该值可能是标识符或别名。使用“模式”URI查询参数时，它可能是标识符、别名或本地化名称。
The default media type [RFC2046] format for returning time zone data is the iCalendar [RFC5545] data format. In addition, the iCalendar-in-XML [RFC6321] and iCalendar-in-JSON [RFC7265] representations are available. Clients use the HTTP Accept header field (see Section 5.3.2 of [RFC7231]) to indicate their preference for the returned data format. Servers indicate the available formats that they support via the "capabilities" action response (Section 5.1).
返回时区数据的默认媒体类型[RFC2046]格式是iCalendar[RFC5545]数据格式。此外，还提供了XML[RFC6321]表示形式的iCalendar和JSON[RFC7265]表示形式的iCalendar。客户机使用HTTP Accept header字段（参见[RFC7231]第5.3.2节）来指示其对返回数据格式的偏好。服务器通过“能力”行动响应（第5.1节）指示其支持的可用格式。
As per Section 3.8, time zone data can support localized names. Clients use the HTTP Accept-Language header field (see Section 5.3.5 of [RFC7231]) to indicate their preference for the language used for localized names in the response data.
根据第3.8节，时区数据可以支持本地化名称。客户机使用HTTP Accept Language标头字段（请参见[RFC7231]第5.3.5节）来指示其对响应数据中本地化名称所用语言的偏好。
When time zone data or metadata changes, it needs to be distributed in a timely manner because changes to local time offsets might occur within a few days of the publication of the time zone data changes. Typically, the number of time zones that change is small, whilst the overall number of time zones can be large. Thus, when a client is using more than a few time zones, it is more efficient for the client to be able to download only those time zones that have changed (an incremental update).
当时区数据或元数据发生更改时，需要及时分发，因为本地时间偏移的更改可能会在发布时区数据更改后的几天内发生。通常，变化的时区数量很小，而时区的总数量可能很大。因此，当客户端使用多个时区时，客户端能够只下载那些已更改的时区（增量更新）更有效。
Clients initially request a full list of time zones from the server using a "list" action request (see Section 5.2). The response to that request includes two items the client caches for use with subsequent "conditional" (incremental update) requests:
客户端最初使用“列表”操作请求从服务器请求完整的时区列表（参见第5.2节）。对该请求的响应包括客户端缓存的两项，用于后续“有条件”（增量更新）请求：
1. An opaque synchronization token in the "synctoken" JSON member. This token changes whenever there is a change to any metadata associated with one or more time zones (where the metadata is the information reported in the "list" action response for each time zone).
1. “synctoken”JSON成员中的不透明同步令牌。每当与一个或多个时区相关联的任何元数据发生更改时（其中元数据是每个时区的“列表”操作响应中报告的信息），该标记就会更改。
2. The HTTP ETag header field value for each time zone returned in the response. The ETag header field value is returned in the "etag" JSON member, and it corresponds to the ETag header field value that would be returned when executing a "get" action request (see Section 5.3) against the corresponding time zone data resource.
2. 响应中返回的每个时区的HTTP ETag标头字段值。ETag头字段值在“ETag”JSON成员中返回，它对应于针对相应时区数据资源执行“get”操作请求（参见第5.3节）时将返回的ETag头字段值。
For subsequent updates to cached data, clients can use the following procedure:
对于缓存数据的后续更新，客户端可以使用以下过程：
a. Send a "list" action request with a "changedsince" URI query parameter with its value set to the last opaque synchronization token returned by the server. The server will return time zone metadata for only those time zones that have changed since the last request.
a. 发送带有“changedsince”URI查询参数的“list”操作请求，其值设置为服务器返回的最后一个不透明同步令牌。服务器将仅返回自上次请求以来已更改的时区的时区元数据。
b. The client will cache the new opaque synchronization token returned in the response for the next incremental update, along with the returned time zone metadata information.
b. 客户端将缓存下一次增量更新响应中返回的新不透明同步令牌以及返回的时区元数据信息。
c. The client will check each time zone metadata to see if the "etag" value is different from that of any cached time zone data it has.
c. 客户端将检查每个时区元数据，以查看“etag”值是否与它所拥有的任何缓存时区数据的值不同。
d. The client will use a "get" action request to update any cached time zone data for those time zones whose ETag header field value has changed.
d. 客户端将使用“get”操作请求更新ETag头字段值已更改的时区的任何缓存时区数据。
Note that time zone metadata will always change when the corresponding time zone data changes. However, the converse is not true: it is possible for some piece of the time zone metadata to change without the corresponding time zone data changing. e.g., for the case of a "monolithic" publisher (see Section 3.10), the version identifier in every time zone metadata element will change with each new published revision; however, only a small subset of time zone data will actually change.
请注意，当相应的时区数据更改时，时区元数据将始终更改。然而，情况并非如此：某些时区元数据可能会发生变化，而相应的时区数据不会发生变化。e、 例如，对于“单一”发布者（见第3.10节），每个时区元数据元素中的版本标识符将随每个新发布的版本而变化；然而，实际上只有一小部分时区数据会发生变化。
If a client needs data for only one or a small set of time zones (e.g., a clock in a fixed location), then it can use a conditional HTTP request to determine if the time zone data has changed and retrieve the new data. The full details of HTTP conditional requests are described in [RFC7232]; what follows is a brief summary of what a client typically does.
如果客户机只需要一个或一小组时区的数据（例如，固定位置的时钟），那么它可以使用条件HTTP请求来确定时区数据是否已更改并检索新数据。[RFC7232]中描述了HTTP条件请求的全部细节；下面是客户通常做什么的简要总结。
a. When the client retrieves the time zone data from the server using a "get" action (see Section 5.3), the server will include an HTTP ETag header field in the response.
a. 当客户端使用“获取”操作从服务器检索时区数据时（参见第5.3节），服务器将在响应中包含HTTP ETag头字段。
b. The client will store the value of that header field along with the request-URI used for the request.
b. 客户端将存储该头字段的值以及用于请求的请求URI。
c. When the client wants to check for an update, it issues another "get" action HTTP request on the original request-URI, but this time it includes an If-None-Match HTTP request header field, with a value set to the ETag header field value from the previous response. If the data for the time zone has not changed, the server will return a 304 (Not Modified) HTTP response. If the data has changed, the server will return a normal HTTP success response that will include the changed data, as well as a new value for the ETag header field.
c. 当客户机想要检查更新时，它会对原始请求URI发出另一个“get”操作HTTP请求，但这次它包含一个If None Match HTTP请求头字段，该字段的值设置为上一个响应中的ETag头字段值。如果时区的数据没有更改，服务器将返回304（未修改）HTTP响应。如果数据已更改，服务器将返回一个正常的HTTP成功响应，该响应将包括更改的数据，以及ETag头字段的新值。
Clients SHOULD poll for changes, using an appropriate conditional request, at least once a day. A server acting as a secondary provider, caching time zone data from another server, SHOULD poll for changes once per hour. See Section 8 on expected client and server behavior regarding high request rates.
客户端应使用适当的条件请求，至少每天轮询一次更改。作为辅助提供程序的服务器缓存来自另一台服务器的时区数据，应每小时轮询一次更改。请参阅第8节，了解有关高请求率的预期客户端和服务器行为。
Determining time zone offsets at a particular point in time is often a complicated process, as the rules for daylight saving time can be complex. To help with this, the time zone data distribution service provides an action that allows clients to request the server to expand a time zone into a set of "observances" over a fixed period of time (see Section 5.4). Each of these observances describes a UTC onset time and UTC offsets for the prior time and the observance time. Together, these provide a quick way for "thin" clients to determine an appropriate UTC offset for an arbitrary date without having to do full time zone expansion themselves.
确定特定时间点的时区偏移通常是一个复杂的过程，因为夏令时的规则可能很复杂。为了帮助实现这一点，时区数据分发服务提供了一个操作，允许客户端请求服务器在固定时间段内将时区扩展为一组“观测”（见第5.4节）。这些观测中的每一项都描述了UTC开始时间以及之前时间和观测时间的UTC偏移量。总之，它们为“瘦”客户端提供了一种快速方法，可以为任意日期确定适当的UTC偏移量，而无需自己进行完整的时区扩展。
To enable a simple client implementation, servers SHOULD ensure that they provide or cache data for all commonly used time zones, from various publishers. That allows client implementations to configure a single server to get all time zone data. In turn, any server can refresh any of the data from any other server -- though the root servers may provide the most up-to-date copy of the data.
为了实现简单的客户端实现，服务器应该确保它们提供或缓存来自不同发布服务器的所有常用时区的数据。这允许客户端实现配置单个服务器以获取所有时区数据。反过来，任何服务器都可以刷新来自任何其他服务器的任何数据——尽管根服务器可能提供数据的最新副本。
When an HTTP error response is returned to the client, the server SHOULD return a JSON "problem details" object in the response body, as per [RFC7807]. Every JSON "problem details" object MUST include a "type" member with a URI value matching the applicable error code (defined for each action in Section 5).
当HTTP错误响应返回到客户机时，服务器应在响应体中返回JSON“问题详细信息”对象，如[RFC7807]所示。每个JSON“problem details”对象必须包含一个“type”成员，其URI值与适用的错误代码相匹配（在第5节中为每个操作定义）。
This protocol is designed to be extensible through a standards-based registration mechanism (see Section 10). It is anticipated that other useful time zone actions will be added in the future (e.g., mapping a geographical location to time zone identifiers, getting change history for time zones), and so, servers MUST return a description of their capabilities. This will allow clients to determine if new features have been installed and, if not, fall back on earlier features or disable some client capabilities.
该协议旨在通过基于标准的注册机制进行扩展（见第10节）。预计将来还会添加其他有用的时区操作（例如，将地理位置映射到时区标识符，获取时区的更改历史记录），因此，服务器必须返回其功能的描述。这将允许客户端确定是否已安装新功能，如果未安装，则返回到以前的功能或禁用某些客户端功能。
Client implementations need to either know where the time zone data distribution service is located or discover it through some mechanism. To use a time zone data distribution service, a client
客户机实现需要知道时区数据分发服务的位置，或者通过某种机制发现它。要使用时区数据分发服务，客户端
needs a Fully Qualified Domain Name (FQDN), port, and HTTP request-URI path. The request-URI path found via discovery is the "context path" for the service itself. The "context path" is used as the value of the "service-prefix" URI template variable when executing actions (see Section 5).
需要完全限定的域名（FQDN）、端口和HTTP请求URI路径。通过发现找到的请求URI路径是服务本身的“上下文路径”。在执行操作时，“上下文路径”用作“服务前缀”URI模板变量的值（参见第5节）。
The following subsections describe two methods of service discovery using DNS SRV records [RFC2782] and an HTTP "well-known" [RFC5785] resource. However, alternative mechanisms could also be used (e.g., a DHCP server option [RFC2131]).
以下小节描述了使用DNS SRV记录[RFC2782]和HTTP“众所周知的”[RFC5785]资源进行服务发现的两种方法。但是，也可以使用替代机制（例如，DHCP服务器选项[RFC2131]）。
[RFC2782] defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using SRV RR records. This can be used to discover a service's FQDN and port.
[RFC2782]定义了一种基于DNS的服务发现协议，该协议已被广泛采用，作为使用SRV RR记录在局域网内外定位特定服务的一种手段。这可用于发现服务的FQDN和端口。
This specification adds two service types for use with SRV records:
本规范添加了两种用于SRV记录的服务类型：
timezone: Identifies a time zone data distribution server that uses HTTP without Transport Layer Security ([RFC2818]).
时区：标识使用HTTP而不使用传输层安全性的时区数据分发服务器（[RFC2818]）。
timezones: Identifies a time zone data distribution server that uses HTTP with Transport Layer Security ([RFC2818]).
时区：标识使用HTTP和传输层安全性（[RFC2818]）的时区数据分发服务器。
Clients MUST honor "TTL", "Priority", and "Weight" values in the SRV records, as described by [RFC2782].
客户必须遵守[RFC2782]所述的SRV记录中的“TTL”、“优先级”和“权重”值。
Example: service record for server without Transport Layer Security.
示例：没有传输层安全性的服务器的服务记录。
_timezone._tcp SRV 0 1 80 tz.example.com.
_时区。_tcpsrv 0 1 80 tz.example.com。
Example: service record for server with transport layer security.
示例：具有传输层安全性的服务器的服务记录。
_timezones._tcp SRV 0 1 443 tz.example.com.
_时区。_tcpsrv 0 1 443 tz.example.com。
When SRV RRs are used to advertise a time zone data distribution service, it is also convenient to be able to specify a "context path" in the DNS to be retrieved at the same time. To enable that, this specification uses a TXT RR that follows the syntax defined in Section 6 of [RFC6763] and defines a "path" key for use in that record. The value of the key MUST be the actual "context path" to the corresponding service on the server.
当SRV RRs用于公布时区数据分发服务时，能够在DNS中同时指定要检索的“上下文路径”也很方便。为了实现这一点，本规范使用了一个TXT RR，它遵循[RFC6763]第6节中定义的语法，并定义了一个在该记录中使用的“路径”键。密钥的值必须是服务器上相应服务的实际“上下文路径”。
A site might provide TXT records in addition to SRV records for each service. When present, clients MUST use the "path" value as the "context path" for the service in HTTP requests. When not present, clients use the ".well-known" URI approach described in Section 4.2.1.3.
除了SRV记录外，站点还可以为每个服务提供TXT记录。当存在时，客户端必须使用“path”值作为HTTP请求中服务的“上下文路径”。当不存在时，客户端使用第4.2.1.3节中描述的“.well-known”URI方法。
As per Section 8, the server MAY require authentication when a client tries to access the path URI specified by the TXT RR (i.e., the server would return a 401 status response to the unauthenticated request from the client, then return a redirect response after a successful authentication by the client).
根据第8节，当客户机试图访问TXT RR指定的路径URI时，服务器可能需要身份验证（即，服务器将对来自客户机的未经身份验证的请求返回401状态响应，然后在客户机成功身份验证后返回重定向响应）。
Example: text record for service with Transport Layer Security.
示例：具有传输层安全性的服务的文本记录。
_timezones._tcp TXT path=/timezones
_时区。\u tcp TXT路径=/时区
A "well-known" URI [RFC5785] is registered by this specification for the Time Zone Data Distribution service, "timezone" (see Section 10). This URI points to a resource that the client can use as the initial "context path" for the service they are trying to connect to. The server MUST redirect HTTP requests for that resource to the actual "context path" using one of the available mechanisms provided by HTTP (e.g., using an appropriate 3xx status response). Clients MUST handle HTTP redirects on the ".well-known" URI, taking into account security restrictions on redirects described in Section 8. Servers MUST NOT locate the actual time zone data distribution service endpoint at the ".well-known" URI as per Section 1.1 of [RFC5785]. The "well-known" URI MUST be present on the server, even when a TXT RR (Section 4.2.1.2) is used in the DNS to specify a "context path".
本规范为时区数据分发服务“timezone”（参见第10节）注册了“众所周知的”URI[RFC5785]。此URI指向一个资源，客户端可以将该资源用作其尝试连接的服务的初始“上下文路径”。服务器必须使用HTTP提供的一种可用机制（例如，使用适当的3xx状态响应）将该资源的HTTP请求重定向到实际的“上下文路径”。客户端必须在“.well-known”URI上处理HTTP重定向，并考虑第8节中描述的重定向的安全限制。根据[RFC5785]第1.1节，服务器不得在“.well-known”URI上定位实际时区数据分发服务端点。即使DNS中使用TXT RR（第4.2.1.2节）来指定“上下文路径”，服务器上也必须存在“已知”URI。
Servers SHOULD set an appropriate Cache-Control header field value (as per Section 5.2 of [RFC7234]) in the redirect response to ensure caching occurs as needed, or as required by the type of response generated. For example, if it is anticipated that the location of the redirect might change over time, then an appropriate "max-age" value would be used.
服务器应在重定向响应中设置适当的缓存控制头字段值（根据[RFC7234]第5.2节），以确保根据需要或根据生成的响应类型进行缓存。例如，如果预期重定向的位置可能会随时间而改变，则将使用适当的“max age”值。
As per Section 8, the server MAY require authentication when a client tries to access the ".well-known" URI (i.e., the server would return a 401 status response to the unauthenticated request from the client, then return the redirect response after a successful authentication by the client).
根据第8节，当客户机试图访问“.well-known”URI时，服务器可能需要身份验证（即，服务器将对来自客户机的未经身份验证的请求返回401状态响应，然后在客户机成功身份验证后返回重定向响应）。
A time zone data distribution server has a "context path" that is "/servlet/timezone". The client will use "/.well-known/timezone" as the path for the service after it has first found the FQDN and port number via an SRV lookup or via manual entry of information by the user. When the client makes its initial HTTP request against "/.well-known/timezone", the server would issue an HTTP 301 redirect response with a Location response header field using the path "/servlet/timezone". The client would then "follow" this redirect to the new resource and continue making HTTP requests there. The client would also cache the redirect information, subject to any Cache-Control directive, for use in subsequent requests.
时区数据分发服务器有一个“上下文路径”，即“/servlet/timezone”。在通过SRV查找或用户手动输入信息首次找到FQDN和端口号后，客户端将使用“/.well-known/timezone”作为服务的路径。当客户端对“/.well-known/timezone”发出初始HTTP请求时，服务器将使用路径“/servlet/timezone”发出HTTP 301重定向响应，其中包含位置响应头字段。然后，客户机将“遵循”这个重定向到新资源，并继续在那里发出HTTP请求。客户端还将根据任何缓存控制指令缓存重定向信息，以便在后续请求中使用。
This section discusses possible client synchronization strategies using the various protocol elements provided by the server for that purpose.
本节讨论使用服务器为此目的提供的各种协议元素的可能的客户端同步策略。
When a secondary service or a client wishing to cache all time zone data first starts, or wishes to do a full refresh, it synchronizes with another server by issuing a "list" action to retrieve all the time zone metadata. The client preserves the returned opaque token for subsequent use (see "synctoken" in Section 5.2.1). The client stores the metadata for each time zone returned in the response. Time zone data for each corresponding time zone can then be fetched and stored locally. In addition, a mapping of aliases to time zones can be built from the metadata. A typical "list" action response size is about 50-100 KB of "pretty printed" JSON data, for a service using the IANA time zone database [RFC6557], as of the time of publication of this specification.
当希望缓存所有时区数据的辅助服务或客户端首次启动或希望执行完全刷新时，它会通过发出“列表”操作来检索所有时区元数据，从而与另一台服务器同步。客户端保留返回的不透明令牌以供后续使用（请参阅第5.2.1节中的“synctoken”）。客户端存储响应中返回的每个时区的元数据。然后，每个对应时区的时区数据可以在本地获取和存储。此外，可以从元数据构建别名到时区的映射。截至本规范发布时，对于使用IANA时区数据库[RFC6557]的服务，典型的“列表”操作响应大小约为50-100KB的“漂亮打印”JSON数据。
A secondary service or a client caching all time zones needs to periodically synchronize with a server. To do so, it issues a "list" action with the "changedsince" URI query parameter set to the value of the opaque token returned by the last synchronization. The client again preserves the returned opaque token for subsequent use. The client updates its stored time zone metadata using the new values returned in the response, which contains just the time zone metadata for those time zones changed since the last synchronization. In addition, it compares the "etag" value in each time zone metadata to the ETag header field value for the corresponding time zone data resource it has previously cached; if they are different, it fetches
缓存所有时区的辅助服务或客户端需要定期与服务器同步。为此，它发出一个“list”操作，将“changedsince”URI查询参数设置为上次同步返回的不透明令牌的值。客户端再次保留返回的不透明令牌以供后续使用。客户端使用响应中返回的新值更新其存储的时区元数据，该值仅包含自上次同步以来更改的那些时区的时区元数据。此外，它将每个时区元数据中的“etag”值与之前缓存的对应时区数据资源的etag头字段值进行比较；如果它们不一样，它会吸引人
the new time zone data. Note that if the client presents the server with a "changedsince" value that the server does not support, all time zone data is returned, as it would for the case where the request did not include a "changedsince" value.
新的时区数据。请注意，如果客户端向服务器提供服务器不支持的“changedsince”值，则会返回所有时区数据，这与请求不包含“changedsince”值的情况相同。
Publishers should take into account the fact that the "outright" deletion of time zone names will cause problems to simple clients, and so aliasing a deleted time zone identifier to a suitable alternate one is preferable.
发布者应该考虑到这样一个事实，即“直接”删除时区名称会给简单的客户端带来问题，因此最好将已删除的时区标识符别名为合适的备用标识符。
A client might be pre-provisioned with time zone data from a source other than the time zone data distribution service it is configured to use. In such cases, the client might want to minimize the amount of time zone data it synchronizes by doing an initial "list" action to retrieve all the time zone metadata, but then only fetch time zone data for those time zones that do not match the publisher and version details for the pre-provisioned data.
客户端可能预先配置了来自其配置为使用的时区数据分发服务以外的源的时区数据。在这种情况下，客户端可能希望通过执行初始“列表”操作来检索所有时区元数据，从而最小化其同步的时区数据量，但随后仅获取与预配置数据的发布者和版本详细信息不匹配的那些时区的时区数据。
Servers MUST support the following actions. The information below shows details about each action: the request-URI the client targets (in the form of a URI template [RFC6570]), a description, the set of allowed query parameters, the nature of the response, and a set of possible error codes for the response (see Section 4.1.7).
服务器必须支持以下操作。下面的信息显示了每个操作的详细信息：客户端目标的请求URI（以URI模板[RFC6570]的形式）、描述、允许的查询参数集、响应的性质以及响应的一组可能的错误代码（参见第4.1.7节）。
For any error not covered by the specific error codes defined below, the "urn:ietf:params:tzdist:error:invalid-action" error code is returned to the client in the JSON "problem details" object.
对于下面定义的特定错误代码未涵盖的任何错误，将在JSON“问题详细信息”对象中将“urn:ietf:params:tzdist:error:invalid action”错误代码返回给客户端。
The examples in the following subsections presume that the timezone context path has been discovered to be "/servlet/timezone" (as in the example in Section 4.2.1.3.1).
以下小节中的示例假定已发现时区上下文路径为“/servlet/timezone”（如第4.2.1.3.1节中的示例所示）。
Name: capabilities
名称：能力
Request-URI Template:
{/service-prefix}/capabilities
Request-URI Template:
{/service-prefix}/capabilities
Description: This action returns the capabilities of the server, allowing clients to determine if a specific feature has been deployed and/or enabled.
描述：此操作返回服务器的功能，允许客户端确定是否已部署和/或启用特定功能。
Parameters: None
Parameters: Nonetranslate error, please retry
Response: A JSON object containing a "version" member, an "info" member, and an "actions" member; see Section 6.1.
响应：一个JSON对象，包含一个“version”成员、一个“info”成员和一个“actions”成员；见第6.1节。
Possible Error Codes: No specific code.
可能的错误代码：没有特定代码。
>> Request <<
>> Request <<
GET /servlet/timezone/capabilities HTTP/1.1
Host: tz.example.com
GET /servlet/timezone/capabilities HTTP/1.1
Host: tz.example.com
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{ "version": 1,
{“版本”：1，
"info": {
"primary-source": "Olson:2011m",
"formats": [
"text/calendar",
"application/calendar+xml",
"application/calendar+json"
],
"truncated" : {
"any": false,
"ranges": [
{
"start": "1970-01-01T00:00:00Z",
"end": "*"
},
{
"start":"2010-01-01T00:00:00Z",
"end":"2020-01-01T00:00:00Z"
}
],
"untruncated": true
},
"provider-details": "http://tz.example.com/about.html",
"contacts": ["mailto:tzs@example.org"]
},
"info": {
"primary-source": "Olson:2011m",
"formats": [
"text/calendar",
"application/calendar+xml",
"application/calendar+json"
],
"truncated" : {
"any": false,
"ranges": [
{
"start": "1970-01-01T00:00:00Z",
"end": "*"
},
{
"start":"2010-01-01T00:00:00Z",
"end":"2020-01-01T00:00:00Z"
}
],
"untruncated": true
},
"provider-details": "http://tz.example.com/about.html",
"contacts": ["mailto:tzs@example.org"]
},
"actions": [
{
"name": "capabilities",
"uri-template": "/servlet/timezone/capabilities",
"parameters": []
},
"actions": [
{
"name": "capabilities",
"uri-template": "/servlet/timezone/capabilities",
"parameters": []
},
{
"name": "list",
"uri-template": "/servlet/timezone/zones{?changedsince}",
"parameters": [
{
"name": "changedsince",
"required": false,
"multi": false
}
]
},
{
"name": "list",
"uri-template": "/servlet/timezone/zones{?changedsince}",
"parameters": [
{
"name": "changedsince",
"required": false,
"multi": false
}
]
},
{
"name": "get",
"uri-template": "/servlet/timezone/zones{/tzid}{?start,end}",
"parameters": [
{
"name": "start",
"required": false,
"multi": false
},
{
"name": "end",
"required": false,
"multi": false
}
]
},
{
"name": "get",
"uri-template": "/servlet/timezone/zones{/tzid}{?start,end}",
"parameters": [
{
"name": "start",
"required": false,
"multi": false
},
{
"name": "end",
"required": false,
"multi": false
}
]
},
{
"name": "expand",
"uri-template":
"/servlet/timezone/zones{/tzid}/observances{?start,end}",
"parameters": [
{
"name": "start",
"required": true,
"multi": false
},
{
"name": "end",
{
"name": "expand",
"uri-template":
"/servlet/timezone/zones{/tzid}/observances{?start,end}",
"parameters": [
{
"name": "start",
"required": true,
"multi": false
},
{
"name": "end",
"required": true,
"multi": false
}
]
},
"required": true,
"multi": false
}
]
},
{
"name": "find",
"uri-template": "/servlet/timezone/zones{?pattern}",
"parameters": [
{
"name": "pattern",
"required": true,
"multi": false
}
]
},
{
"name": "find",
"uri-template": "/servlet/timezone/zones{?pattern}",
"parameters": [
{
"name": "pattern",
"required": true,
"multi": false
}
]
},
{
"name": "leapseconds",
"uri-template": "/servlet/timezone/leapseconds",
"parameters": []
}
]
}
{
"name": "leapseconds",
"uri-template": "/servlet/timezone/leapseconds",
"parameters": []
}
]
}
Name: list
姓名：名单
Request-URI Template:
{/service-prefix,data-prefix}/zones{?changedsince}
Request-URI Template:
{/service-prefix,data-prefix}/zones{?changedsince}
Description: This action lists all time zone identifiers in summary format, with publisher, version, aliases, and optional localized data. In addition, it returns an opaque synchronization token for the entire response. If the "changedsince" URI query parameter is present, its value MUST correspond to a previously returned synchronization token value. When "changedsince" is used, the server MUST return only those time zones that have changed since the specified synchronization token. If the "changedsince" value is not supported by the server, the server MUST return all time zones, treating the request as if it had no "changedsince".
描述：此操作以摘要格式列出所有时区标识符，包括发布者、版本、别名和可选的本地化数据。此外，它还为整个响应返回一个不透明的同步令牌。如果存在“changedsince”URI查询参数，则其值必须对应于先前返回的同步令牌值。使用“changedsince”时，服务器必须仅返回自指定同步令牌以来已更改的时区。如果服务器不支持“changedsince”值，则服务器必须返回所有时区，将请求视为没有“changedsince”。
Parameters:
参数：
changedsince OPTIONAL, and MUST NOT occur more than once.
更改是可选的，并且不能出现多次。
Response: A JSON object containing a "synctoken" member and a "timezones" member; see Section 6.2.
响应：包含“synctoken”成员和“timezones”成员的JSON对象；见第6.2节。
Possible Error Codes:
可能的错误代码：
urn:ietf:params:tzdist:error:invalid-changedsince
urn:ietf:params:tzdist:error:invalid-changedsince
The "changedsince" URI query parameter appears more than once.
“changedsince”URI查询参数多次出现。
In this example the client requests the full set of time zone identifiers.
在此示例中，客户端请求完整的时区标识符集。
>> Request <<
>> Request <<
GET /servlet/timezone/zones HTTP/1.1
Host: tz.example.com
GET /servlet/timezone/zones HTTP/1.1
Host: tz.example.com
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"synctoken": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"etag": "123456789-000-111",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
...other time zones...
]
}
{
"synctoken": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"etag": "123456789-000-111",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
...other time zones...
]
}
Name: get
姓名：get
Request-URI Template:
{/service-prefix,data-prefix}/zones{/tzid}{?start,end}
Request-URI Template:
{/service-prefix,data-prefix}/zones{/tzid}{?start,end}
The "tzid" variable value is REQUIRED in order to distinguish this action from the "list" action.
需要“tzid”变量值以区分此操作与“列表”操作。
Description: This action returns a time zone. The response MUST contain an ETag response header field indicating the current value of the strong entity tag of the time zone resource.
描述：此操作返回时区。响应必须包含ETag响应头字段，该字段指示时区资源的强实体标记的当前值。
In the absence of any Accept HTTP request header field, the server MUST return time zone data with the "text/calendar" media type.
如果没有任何Accept HTTP request header字段，服务器必须返回“text/calendar”媒体类型的时区数据。
If the "tzid" variable value is actually a time zone alias, the server will return the matching time zone data with the alias as the identifier in the time zone data. The server MAY include one or more "TZID-ALIAS-OF" properties (see Section 7.2) in the time zone data to indicate additional identifiers that have the matching time zone identifier as an alias.
如果“tzid”变量值实际上是一个时区别名，服务器将返回匹配的时区数据，该别名作为时区数据中的标识符。服务器可在时区数据中包含一个或多个“TZID-ALIAS-OF”属性（参见第7.2节），以指示将匹配的时区标识符作为别名的其他标识符。
Parameters:
参数：
start=<date-time> OPTIONAL, and MUST NOT occur more than once. Specifies the inclusive UTC date-time value at which the returned time zone data is truncated at its start.
开始=<date-time>可选，不能出现多次。指定返回的时区数据在开始时被截断的包含UTC日期时间值。
end=<date-time> OPTIONAL, and MUST NOT occur more than once. Specifies the exclusive UTC date-time value at which the returned time zone data is truncated at its end.
end=<date-time>可选，不能出现多次。指定在返回的时区数据结束时截断的唯一UTC日期时间值。
Response: A document containing all the requested time zone data in the format specified.
响应：以指定格式包含所有请求的时区数据的文档。
Possible Error Codes:
可能的错误代码：
urn:ietf:params:tzdist:error:tzid-not-found No time zone associated with the specified "tzid" path segment value was found.
urn:ietf:params:tzdist:error:tzid未找到与指定的“tzid”路径段值关联的时区。
urn:ietf:params:tzdist:error:invalid-format The Accept request header field supplied by the client did not contain a media type for time zone data supported by the server.
urn:ietf:params:tzdist:error:格式无效客户端提供的接受请求标头字段不包含服务器支持的时区数据的媒体类型。
urn:ietf:params:tzdist:error:invalid-start The "start" URI query parameter has an incorrect value, or appears more than once, or does not match one of the fixed truncation range start values advertised in the "capabilities" action response.
urn:ietf:params:tzdist:error:invalid start“start”URI查询参数的值不正确，或出现多次，或与“capabilities”操作响应中公布的固定截断范围起始值之一不匹配。
urn:ietf:params:tzdist:error:invalid-end The "end" URI query parameter has an incorrect value, or appears more than once, or has a value less than or equal to the "start" URI query parameter, or does not match one of the fixed truncation range end values advertised in the "capabilities" action response.
urn:ietf:params:tzdist:error:invalid end“end”URI查询参数的值不正确，或出现多次，或值小于或等于“start”URI查询参数，或与“capabilities”操作响应中公布的固定截断范围结束值之一不匹配。
In this example, the client requests that the time zone with a specific time zone identifier be returned.
在本例中，客户端请求返回具有特定时区标识符的时区。
>> Request <<
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
Host: tz.example.com
Accept:text/calendar
GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
Host: tz.example.com
Accept:text/calendar
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
BEGIN:VCALENDAR ... BEGIN:VTIMEZONE TZID:America/New_York ... END:VTIMEZONE END:VCALENDAR
开始：VCALENDAR。。。开始：VTIMEZONE TZID:美国/纽约。。。结束：VTIMEZONE结束：VCALENDAR
In this example the client requests that the time zone with a specific time zone identifier be returned, but uses an If-None-Match header field in the request, set to the value of a previously returned ETag header field, or the value of the "etag" member in a JSON "timezone" object returned from a "list" action response. In this example, the data on the server has not changed, so a 304 response is returned.
在本例中，客户端请求返回具有特定时区标识符的时区，但在请求中使用If None Match头字段，设置为先前返回的ETag头字段的值，或从“list”操作响应返回的JSON“timezone”对象中的“ETag”成员的值。在本例中，服务器上的数据没有更改，因此返回304响应。
>> Request <<
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
Host: tz.example.com
Accept:text/calendar
If-None-Match: "123456789-000-111"
GET /servlet/timezone/zones/America%2FNew_York HTTP/1.1
Host: tz.example.com
Accept:text/calendar
If-None-Match: "123456789-000-111"
>> Response <<
>> Response <<
HTTP/1.1 304 Not Modified
Date: Wed, 4 Jun 2008 09:32:12 GMT
HTTP/1.1 304 Not Modified
Date: Wed, 4 Jun 2008 09:32:12 GMT
In this example, the client requests that the time zone with an aliased time zone identifier be returned, and the server returns the time zone data with that identifier and two aliases.
在本例中，客户端请求返回带有别名时区标识符的时区，服务器返回带有该标识符和两个别名的时区数据。
>> Request <<
>> Request <<
GET /servlet/timezone/zones/US%2FEastern HTTP/1.1
Host: tz.example.com
Accept:text/calendar
GET /servlet/timezone/zones/US%2FEastern HTTP/1.1
Host: tz.example.com
Accept:text/calendar
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
BEGIN:VCALENDAR
...
BEGIN:VTIMEZONE
TZID:US/Eastern
TZID-ALIAS-OF:America/New_York
TZID-ALIAS-OF:America/Montreal
BEGIN:VCALENDAR
...
BEGIN:VTIMEZONE
TZID:US/Eastern
TZID-ALIAS-OF:America/New_York
TZID-ALIAS-OF:America/Montreal
... END:VTIMEZONE END:VCALENDAR
... 结束：VTIMEZONE结束：VCALENDAR
Assume the server advertises a "truncated" object in its "capabilities" response that appears as:
假设服务器在其“功能”响应中播发一个“被截断”的对象，该响应显示为：
"truncated": {
"any": false,
"ranges": [
{"start": "1970-01-01T00:00:00Z", "end": "*"},
{"start":"2010-01-01T00:00:00Z", "end":"2020-01-01T00:00:00Z"}
],
"untruncated": false
}
"truncated": {
"any": false,
"ranges": [
{"start": "1970-01-01T00:00:00Z", "end": "*"},
{"start":"2010-01-01T00:00:00Z", "end":"2020-01-01T00:00:00Z"}
],
"untruncated": false
}
In this example, the client requests that the time zone with a specific time zone identifier truncated at one of the ranges specified by the server be returned. Note the presence of a "STANDARD" component that matches the start point of the truncation range (converted to the local time for the UTC offset in effect at the matching UTC time). Also, note the presence of the "TZUNTIL" (Section 7.1) iCalendar property in the "VTIMEZONE" component, indicating the upper bound on the validity period of the time zone data.
在本例中，客户端请求返回特定时区标识符在服务器指定的某个范围内被截断的时区。请注意，存在与截断范围起点相匹配的“标准”组件（转换为本地时间，用于匹配UTC时间生效的UTC偏移）。此外，请注意“VTIMEZONE”组件中存在“TZTILL”（第7.1节）iCalendar属性，表示时区数据有效期的上限。
>> Request <<
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York
?start=2010-01-01T00:00:00Z&end=2020-01-01T00:00:00Z HTTP/1.1
Host: tz.example.com
Accept:text/calendar
GET /servlet/timezone/zones/America%2FNew_York
?start=2010-01-01T00:00:00Z&end=2020-01-01T00:00:00Z HTTP/1.1
Host: tz.example.com
Accept:text/calendar
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: text/calendar; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
BEGIN:VCALENDAR ... BEGIN:VTIMEZONE TZID:America/New_York TZUNTIL:20200101T000000Z
开始：VCALENDAR。。。开始：VTIMEZONE TZID:美国/纽约TZID:20200101T000000Z
BEGIN:STANDARD DTSTART:20101231T190000 TZNAME:EST TZOFFSETFROM:-0500 TZOFFSETTO:-0500 END:STANDARD ... END:VTIMEZONE END:VCALENDAR
开始：标准DTSTART:20101231T190000 TZNAME:EST TZOFFSETFROM:-0500 TZOFFSETTO:-0500结束：标准。。。结束：VTIMEZONE结束：VCALENDAR
In this example, the client requests that the time zone with a specific time zone identifier be returned. As it turns out, no time zone exists with that identifier.
在本例中，客户端请求返回具有特定时区标识符的时区。事实证明，不存在具有该标识符的时区。
>> Request <<
>> Request <<
GET /servlet/timezone/zones/America%2FPittsburgh HTTP/1.1
Host: tz.example.com
Accept:application/calendar+json
GET /servlet/timezone/zones/America%2FPittsburgh HTTP/1.1
Host: tz.example.com
Accept:application/calendar+json
>> Response <<
>> Response <<
HTTP/1.1 404 Not Found
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/problem+json; charset="utf-8"
Content-Language: en
Content-Length: xxxx
HTTP/1.1 404 Not Found
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/problem+json; charset="utf-8"
Content-Language: en
Content-Length: xxxx
{
"type": "urn:ietf:params:tzdist:error:tzid-not-found",
"title": "Time zone identifier was not found on this server",
"status": 404
}
{
"type": "urn:ietf:params:tzdist:error:tzid-not-found",
"title": "Time zone identifier was not found on this server",
"status": 404
}
Name: expand
名称：展开
Request-URI Template:
{/service-prefix,data-prefix}/zones{/tzid}/observances{?start,end}
Request-URI Template:
{/service-prefix,data-prefix}/zones{/tzid}/observances{?start,end}
The "tzid" variable value is REQUIRED.
“tzid”变量值是必需的。
Description: This action expands the specified time zone into a list of onset start date/time values (in UTC) and UTC offsets. The response MUST contain an ETag response header field indicating the current value of the strong entity tag of the time zone being expanded.
描述：此操作将指定时区扩展为开始日期/时间值（UTC）和UTC偏移量的列表。响应必须包含一个ETag响应头字段，该字段指示正在扩展的时区的强实体标记的当前值。
Parameters:
参数：
start=<date-time>: REQUIRED, and MUST occur only once. Specifies the inclusive UTC date-time value for the start of the period of interest.
开始=<date-time>：必需，并且只能出现一次。指定感兴趣期间开始时包含的UTC日期时间值。
end=<date-time>: REQUIRED, and MUST occur only once. Specifies the exclusive UTC date-time value for the end of the period of interest. Note that this is the exclusive end value, i.e., it represents the date just after the range of interest. For if a client wants the expanded date just for the year 2014, it would use a start value of "2014-01-01T00:00:00Z" and an end value of "2015-01-01T00:00:00Z". An error occurs if the end value is less than or equal to the start value.
end=<date-time>：必需，并且只能出现一次。指定感兴趣期间结束时的唯一UTC日期时间值。请注意，这是唯一的结束值，也就是说，它表示兴趣范围之后的日期。因为，如果客户希望扩展日期仅适用于2014年，则应使用“2014-01-01T00:00:00Z”的起始值和“2015-01-01T00:00:00Z”的结束值。如果结束值小于或等于开始值，则会发生错误。
Response: A JSON object containing a "tzid" member and an "observances" member; see Section 6.3. If the time zone being expanded is not fully defined over the requested time range (e.g., because of truncation), then the server MUST include "start" and/ or "end" members in the JSON response to indicate the actual start and end points for the observances being returned. The server MUST include an expanded observance representing the time zone information in effect at the start of the returned observance period.
响应：一个JSON对象，包含一个“tzid”成员和一个“Observations”成员；见第6.3节。如果在请求的时间范围内未完全定义要扩展的时区（例如，由于截断），则服务器必须在JSON响应中包含“开始”和/或“结束”成员，以指示返回的观测的实际开始点和结束点。服务器必须包含一个扩展的观测值，表示在返回的观测周期开始时有效的时区信息。
Possible Error Codes
可能的错误代码
urn:ietf:params:tzdist:error:tzid-not-found No time zone associated with the specified "tzid" path segment value was found.
urn:ietf:params:tzdist:error:tzid未找到与指定的“tzid”路径段值关联的时区。
urn:ietf:params:tzdist:error:invalid-start The "start" URI query parameter has an incorrect value, or appears more than once, or is missing, or has a value outside any fixed truncation ranges advertised in the "capabilities" action response.
urn:ietf:params:tzdist:error:invalid start“start”URI查询参数的值不正确，或出现多次，或丢失，或其值超出“capabilities”操作响应中公布的任何固定截断范围。
urn:ietf:params:tzdist:error:invalid-end
The "end" URI query parameter has an incorrect value, or
appears more than once, or has a value less than or equal to
urn:ietf:params:tzdist:error:invalid-end
The "end" URI query parameter has an incorrect value, or
appears more than once, or has a value less than or equal to
the "start" URI query parameter, or has a value outside any fixed truncation ranges advertised in the "capabilities" action response.
“start”URI查询参数，或其值超出“capabilities”操作响应中公布的任何固定截断范围。
In this example, the client requests a time zone in the expanded form.
在本例中，客户机请求扩展形式的时区。
>> Request <<
>> Request <<
GET /servlet/timezone/zones/America%2FNew_York/observances
?start=2008-01-01T00:00:00Z&end=2009-01-01T00:00:00Z HTTP/1.1
Host: tz.example.com
GET /servlet/timezone/zones/America%2FNew_York/observances
?start=2008-01-01T00:00:00Z&end=2009-01-01T00:00:00Z HTTP/1.1
Host: tz.example.com
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Mon, 11 Oct 2009 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
HTTP/1.1 200 OK
Date: Mon, 11 Oct 2009 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
ETag: "123456789-000-111"
{
"tzid": "America/New_York",
"observances": [
{
"name": "Standard",
"onset": "2008-01-01T00:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -18000
},
{
"name": "Daylight",
"onset": "2008-03-09T07:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -14400
},
{
"name": "Standard",
"onset": "2008-11-02T06:00:00Z",
"utc-offset-from": -14400,
"utc-offset-to": -18000
},
]
}
{
"tzid": "America/New_York",
"observances": [
{
"name": "Standard",
"onset": "2008-01-01T00:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -18000
},
{
"name": "Daylight",
"onset": "2008-03-09T07:00:00Z",
"utc-offset-from": -18000,
"utc-offset-to": -14400
},
{
"name": "Standard",
"onset": "2008-11-02T06:00:00Z",
"utc-offset-from": -14400,
"utc-offset-to": -18000
},
]
}
Name: find
姓名：查找
Request-URI Template:
{/service-prefix,data-prefix}/zones{?pattern}
Request-URI Template:
{/service-prefix,data-prefix}/zones{?pattern}
Description: This action allows a client to query the time zone data distribution service for a matching identifier, alias, or localized name, using a simple "glob" style patter match against the names known to the server (with an asterisk (*) as the wildcard character). Pattern-match strings (which have to be percent-encoded and then decoded when used in the URI query parameter) have the following options:
描述：此操作允许客户端使用简单的“全局”样式模式匹配服务器已知的名称（以星号（*）作为通配符），向时区数据分发服务查询匹配的标识符、别名或本地化名称。模式匹配字符串（在URI查询参数中使用时必须进行百分比编码然后解码）具有以下选项：
* not present: An exact text match is done, e.g., "xyz"
* 不存在：已完成精确的文本匹配，例如“xyz”
* first character only: An ends-with text match is done, e.g., "*xyz"
* 仅第一个字符：以文本匹配结束，例如“*xyz”
* last character only: A starts-with text match is done, e.g., "xyz*"
* 仅最后一个字符：以文本匹配开始的字符已完成，例如“xyz*”
* first and last characters only: A substring text match is done, e.g., "*xyz*"
* 仅第一个和最后一个字符：完成子字符串文本匹配，例如“*xyz*”
Escaping \ and *: To match 0x2A ("*") and 0x5C ("\") characters in a time zone identifier, those characters have to be "escaped" in the pattern by prepending a single 0x5C ("\") character. For example, a pattern "\*Test\\Time\*Zone\*" is used for an exact match against the time zone identifier "*Test\Time*Zone*". An unescaped "*" character MUST NOT appear in the middle of the string and MUST result in an error. An unescaped "\" character MUST NOT appear anywhere in the string and MUST result in an error.
转义\和*：要匹配时区标识符中的0x2A（“*”）和0x5C（“\”）字符，必须在模式中通过在单个0x5C（“\”）字符前加前缀来“转义”这些字符。例如，模式“\*Test\\Time\*Zone\*”用于与时区标识符“*Test\Time*Zone*”精确匹配。一个未转义的“*”字符不能出现在字符串的中间，并且必须导致错误。未转义的“\”字符不得出现在字符串中的任何位置，并且必须导致错误。
In addition, when matching:
此外，匹配时：
Underscores: Underscore characters (0x5F) in time zone identifiers MUST be mapped to a single space character (0x20) prior to string comparison in both the pattern and time zone identifiers being matched. This allows time zone identifiers such as "America/New_York" to match a query for "*New York*".
下划线：时区标识符中的下划线字符（0x5F）必须映射到单个空格字符（0x20），然后才能在匹配的模式标识符和时区标识符中进行字符串比较。这允许时区标识符（如“美国/纽约”）与“*纽约*”的查询相匹配。
Case mapping: ASCII characters in the range 0x41 ("A") through 0x5A ("Z") MUST be mapped to their lowercase equivalents in both the pattern and time zone identifiers being matched.
大小写映射：0x41（“A”）到0x5A（“Z”）范围内的ASCII字符必须在匹配的模式标识符和时区标识符中映射为其小写等效字符。
Parameters:
参数：
pattern=<text> REQUIRED, and MUST occur only once.
pattern=<text>是必需的，并且只能出现一次。
Response: The response has the same format as the "list" action, with one result object per successful match; see Section 6.2.
响应：响应的格式与“列表”操作相同，每成功匹配一个结果对象；见第6.2节。
Possible Error Codes
可能的错误代码
urn:ietf:params:tzdist:error:invalid-pattern The "pattern" URI query parameter has an incorrect value or appears more than once.
urn:ietf:params:tzdist:error:invalid pattern“pattern”URI查询参数的值不正确或出现多次。
In this example, the client asks for data about the time zone "US/Eastern".
在本例中，客户机要求提供有关时区“美国/东部”的数据。
>> Request <<
>> Request <<
GET /servlet/timezone/zones?pattern=US/Eastern HTTP/1.1
Host: tz.example.com
GET /servlet/timezone/zones?pattern=US/Eastern HTTP/1.1
Host: tz.example.com
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"synctoken": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"etag": "123456789-000-111",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
{
"synctoken": "2009-10-11T09:32:11Z",
"timezones": [
{
"tzid": "America/New_York",
"etag": "123456789-000-111",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/New_York",
"lang": "en_US"
}
]
},
{
"tzid": "America/Detroit",
"etag": "123456789-999-222",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/Detroit",
"lang": "en_US"
}
]
},
...
]
}
{
"tzid": "America/Detroit",
"etag": "123456789-999-222",
"last-modified": "2009-09-17T01:39:34Z",
"publisher": "Example.com",
"version": "2015a",
"aliases":["US/Eastern"],
"local-names": [
{
"name": "America/Detroit",
"lang": "en_US"
}
]
},
...
]
}
Name: leapseconds
姓名：leapseconds
Request-URI Template:
{/service-prefix,data-prefix}/leapseconds
Request-URI Template:
{/service-prefix,data-prefix}/leapseconds
Description: This action allows a client to query the time zone data distribution service to retrieve the current leap-second information available on the server.
描述：此操作允许客户端查询时区数据分发服务，以检索服务器上可用的当前闰秒信息。
Parameters: None
参数：无
Response: A JSON object containing an "expires" member, a "publisher" member, a "version" member, and a "leapseconds" member; see Section 6.4. The "expires" member in the JSON response indicates the latest date covered by leap-second information. For example (as in Section 5.6.1), if the "expires" value is set to "2014-06-28" and the latest leap-second change indicated was at "2012-07-01", then the data indicates that there are no leap seconds added (or removed) between those two dates, and information for leap seconds beyond the "expires" date is not yet available.
响应：一个JSON对象，包含一个“expires”成员、“publisher”成员、“version”成员和一个“leapseconds”成员；见第6.4节。JSON响应中的“expires”成员表示闰秒信息覆盖的最新日期。例如（如第5.6.1节所述），如果“expires”值设置为“2014-06-28”，并且最新的闰秒变化显示为“2012-07-01”，则数据表明这两个日期之间没有增加（或删除）闰秒，并且“expires”日期之后的闰秒信息尚不可用。
The "leapseconds" member contains a list of JSON objects each of which contains a "utc-offset" and "onset" member. The "onset" member specifies the date (with the implied time of 00:00:00 UTC) at which the corresponding UTC offset from TAI takes effect. In other words, a leap second is added or removed just prior to time 00:00:00 UTC of the specified onset date. When a leap second is
“leapseconds”成员包含一个JSON对象列表，每个对象都包含一个“utc偏移量”和“开始”成员。“开始”成员指定与TAI对应的UTC偏移生效的日期（隐含时间为00:00:00 UTC）。换句话说，在指定开始日期的UTC时间00:00:00之前添加或删除闰秒。当闰秒
added, the "utc-offset" value will be incremented by one; when a leap second is removed, the "utc-offset" value will be decremented by one.
添加后，“utc偏移”值将增加1；删除闰秒后，“utc偏移”值将减少一。
Possible Error Codes No specific code.
可能的错误代码无特定代码。
In this example, the client requests the current leap-second information from the server.
在本例中，客户端从服务器请求当前闰秒信息。
>> Request <<
>> Request <<
GET /servlet/timezone/leapseconds HTTP/1.1
Host: tz.example.com
GET /servlet/timezone/leapseconds HTTP/1.1
Host: tz.example.com
>> Response <<
>> Response <<
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
HTTP/1.1 200 OK
Date: Wed, 4 Jun 2008 09:32:12 GMT
Content-Type: application/json; charset="utf-8"
Content-Length: xxxx
{
"expires": "2015-12-28",
"publisher": "Example.com",
"version": "2015d",
"leapseconds": [
{
"utc-offset": 10,
"onset": "1972-01-01",
},
{
"utc-offset": 11,
"onset": "1972-07-01",
},
...
{
"utc-offset": 35,
"onset": "2012-07-01",
},
{
"utc-offset": 36,
"onset": "2015-07-01",
}
]
}
{
"expires": "2015-12-28",
"publisher": "Example.com",
"version": "2015d",
"leapseconds": [
{
"utc-offset": 10,
"onset": "1972-01-01",
},
{
"utc-offset": 11,
"onset": "1972-07-01",
},
...
{
"utc-offset": 35,
"onset": "2012-07-01",
},
{
"utc-offset": 36,
"onset": "2015-07-01",
}
]
}
[RFC7159] defines the structure of JSON objects using a set of primitive elements. The structure of JSON objects used by this specification is described by the following set of rules:
[RFC7159]使用一组基本元素定义JSON对象的结构。本规范使用的JSON对象的结构由以下一组规则描述：
OBJECT represents a JSON object, defined in Section 4 of [RFC7159]. "OBJECT" is followed by a parenthesized list of "MEMBER" rule names. If a member rule name is preceded by a "?" (0x3F) character, that member is optional; otherwise, all members are required. If two or more member rule names are present, each separated from the other by a "|" (0x7C) character, then only one of those members MUST be present in the JSON object. JSON object members are unordered, and thus the order used in the rules is not significant.
对象表示[RFC7159]第4节中定义的JSON对象。“对象”后面是一个括号内的“成员”规则名称列表。如果成员规则名称前面有“？”（0x3F）字符，则该成员是可选的；否则，需要所有成员。如果存在两个或多个成员规则名称，每个名称之间用“|”（0x7C）字符分隔，则JSON对象中只能存在其中一个成员。JSON对象成员是无序的，因此规则中使用的顺序并不重要。
MEMBER represents a member of a JSON object, defined in Section 4 of [RFC7159]. "MEMBER" is followed by a rule name, the name of the member, a ":", and then the value. A value can be one of "OBJECT", "ARRAY", "NUMBER", "STRING", or "BOOLEAN" rules.
成员表示[RFC7159]第4节中定义的JSON对象的成员。“MEMBER”后跟规则名称、成员名称、“：”，然后是值。值可以是“对象”、“数组”、“数字”、“字符串”或“布尔”规则之一。
ARRAY represents a JSON array, defined in Section 5 of [RFC7159]. "ARRAY" is followed by a value (one of "OBJECT", "ARRAY", "NUMBER", "STRING", or "BOOLEAN"), indicating the type of items used in the array.
数组表示[RFC7159]第5节中定义的JSON数组。“ARRAY”后面跟着一个值（“OBJECT”、“ARRAY”、“NUMBER”、“STRING”或“BOOLEAN”）指示数组中使用的项的类型。
NUMBER represents a JSON number, defined in Section 6 of [RFC7159].
数字表示[RFC7159]第6节中定义的JSON编号。
STRING represents a JSON string, defined in Section 7 of [RFC7159].
STRING表示一个JSON字符串，在[RFC7159]的第7节中定义。
BOOLEAN represents either of the JSON values "true" or "false", defined in Section 3 of [RFC7159].
布尔值表示[RFC7159]第3节中定义的JSON值“true”或“false”。
; a line starting with a ";" (0x3B) character is a comment.
; 以“；”（0x3B）字符开头的行是注释。
Note, clients MUST ignore any unexpected JSON members in responses from the server.
注意，客户端必须忽略服务器响应中任何意外的JSON成员。
Below are the rules for the JSON document returned for a "capabilities" action request.
下面是为“功能”操作请求返回的JSON文档的规则。
; root object OBJECT (version, info, actions)
; 根对象（版本、信息、操作）
; The version number of the protocol supported - MUST be 1 MEMBER version "version" : NUMBER
; 支持的协议的版本号-必须是1个成员版本“版本”：编号
; object containing service information ; Only one of primary_source or secondary_source MUST be present MEMBER info "info" : OBJECT ( primary_source | secondary_source, formats, ?truncated, ?provider_details, ?contacts )
; 包含服务信息的对象；只有一个主要源或次要源必须存在成员信息“info”：对象（主要源、次要源、格式、截断、提供商详细信息、联系人）
; The source of the time zone data provided by a "primary" server MEMBER primary_source "primary-source" : STRING
; “主要”服务器成员提供的时区数据源主要\ u源“主要源”：字符串
; The time zone data server from which data is provided by a ; "secondary" server MEMBER secondary_source "secondary-source" : STRING
; 时区数据服务器，数据由服务器提供；“secondary”服务器成员secondary_source“secondary source”：字符串
; Array of one or more media types for the time zone data formats ; that the server can return MEMBER formats "formats" : ARRAY STRING
; 时区数据格式的一种或多种媒体类型的数组；服务器可以返回成员格式“formats”：数组字符串
; Present if the server is providing truncated time zone data. The
; value is an object providing details of the supported truncation
; modes.
MEMBER truncated "truncated" : OBJECT: (
any,
?ranges,
?untruncated
)
; Present if the server is providing truncated time zone data. The
; value is an object providing details of the supported truncation
; modes.
MEMBER truncated "truncated" : OBJECT: (
any,
?ranges,
?untruncated
)
; Indicates whether the server can truncate time zone data at any
; start or end point. When set to "true", any start or end point is
; a valid value for use with the "start" and "end" URI query
; parameters in a "get" action request.
MEMBER any "any" : BOOLEAN
; Indicates whether the server can truncate time zone data at any
; start or end point. When set to "true", any start or end point is
; a valid value for use with the "start" and "end" URI query
; parameters in a "get" action request.
MEMBER any "any" : BOOLEAN
; Indicates which ranges of time the server has truncated data for.
; A value from this list may be used with the "start" and "end" URI
; query parameters in a "get" action request. Not present if "any"
; is set to "true".
MEMBER ranges "ranges" : ARRAY OBJECT (range-start, range-end)
; Indicates which ranges of time the server has truncated data for.
; A value from this list may be used with the "start" and "end" URI
; query parameters in a "get" action request. Not present if "any"
; is set to "true".
MEMBER ranges "ranges" : ARRAY OBJECT (range-start, range-end)
; UTC date-time value (per [RFC3339]) for inclusive start of the
; range, or the single character "*" to indicate a value
; corresponding to the lower bound supplied by the publisher of the
; time zone data
MEMBER range-start "start" : STRING
; UTC date-time value (per [RFC3339]) for inclusive start of the
; range, or the single character "*" to indicate a value
; corresponding to the lower bound supplied by the publisher of the
; time zone data
MEMBER range-start "start" : STRING
; UTC date-time value (per [RFC3339]) for exclusive end of the range,
; or the single character "*" to indicate a value corresponding to
; the upper bound supplied by the publisher of the time zone data
MEMBER range-end "end" : STRING
; UTC date-time value (per [RFC3339]) for exclusive end of the range,
; or the single character "*" to indicate a value corresponding to
; the upper bound supplied by the publisher of the time zone data
MEMBER range-end "end" : STRING
; Indicates whether the server can supply untruncated data. When
; set to "true", indicates that, in addition to truncated data being
; available, the server can return untruncated data if a "get"
; action request is executed without a "start" or "end" URI query
; parameter.
MEMBER untruncated "untruncated" : BOOLEAN
; Indicates whether the server can supply untruncated data. When
; set to "true", indicates that, in addition to truncated data being
; available, the server can return untruncated data if a "get"
; action request is executed without a "start" or "end" URI query
; parameter.
MEMBER untruncated "untruncated" : BOOLEAN
; A URI where human-readable details about the time zone service ; is available MEMBER provider_details "provider-details" : STRING
; 一个URI，其中有关于时区服务的人类可读的详细信息；是否有可用的成员提供程序\u详细信息“提供程序详细信息”：字符串
; Array of URIs providing contact details for the server ; administrator MEMBER contacts "contacts" : ARRAY STRING
; 提供服务器联系详细信息的URI数组；管理员成员联系人“联系人”：数组字符串
; Array of actions supported by the server MEMBER actions "actions" : ARRAY OBJECT ( action_name, action_params )
; 服务器成员操作“actions”支持的操作数组：数组对象（操作名称、操作参数）
; Name of the action MEMBER action_name: "name" : STRING
; 操作成员的名称操作名称：“名称”：字符串
; Array of request-URI query parameters supported by the action MEMBER action_params: "parameters" ARRAY OBJECT ( param_name, ?param_required, ?param_multi, ?param_values )
; 操作成员action_params支持的请求URI查询参数数组：“parameters”数组对象（param_name、？param_required、？param_multi、？param_value）
; Name of the parameter MEMBER param_name "name" : STRING
; 参数成员param_Name“Name”的名称：STRING
; If true, the parameter has to be present in the request-URI ; default is false MEMBER param_required "required" : BOOLEAN
; 如果为true，则参数必须存在于请求URI中；默认值为false成员参数required“required”：布尔值
; If true, the parameter can occur more than once in the request-URI ; default is false MEMBER param_multi "multi" : BOOLEAN,
; 如果为true，则参数可以在请求URI中出现多次；默认值为false成员参数multi“multi”：布尔值，
; An array that defines the allowed set of values for the parameter ; In the absence of this member, any string value is acceptable MEMBER param_values "values" ARRAY STRING
; 定义参数允许值集的数组；如果没有此成员，任何字符串值都是可接受的成员param_values“values”数组字符串
Below are the rules for the JSON document returned for a "list" or "find" action request.
下面是针对“列表”或“查找”操作请求返回的JSON文档的规则。
; root object OBJECT (synctoken, timezones)
; 根对象对象（同步令牌、时区）
; Server-generated opaque token used for synchronizing changes MEMBER synctoken "synctoken" : STRING
; 服务器生成的不透明令牌用于同步更改成员synctoken“synctoken”：字符串
; Array of time zone objects MEMBER timezones "timezones" : ARRAY OBJECT ( tzid, etag, last_modified, publisher, version, ?aliases, ?local_names, )
; 时区对象数组成员时区“时区”：数组对象（tzid、etag、上次修改、发布者、版本、别名、本地名称）
; Time zone identifier MEMBER tzid "tzid" : STRING
; 时区标识符成员tzid“tzid”：字符串
; Current ETag for the corresponding time zone data resource MEMBER etag "etag" : STRING
; 对应时区数据资源成员ETag“ETag”的当前ETag:STRING
; Date/time when the time zone data was last modified ; UTC date-time value as specified in [RFC3339] MEMBER last_modified "last-modified" : STRING
; 上次修改时区数据的日期/时间；[RFC3339]成员上次修改“上次修改”中指定的UTC日期时间值：字符串
; Time zone data publisher MEMBER publisher "publisher" : STRING
; 时区数据发布者成员发布者“发布者”：字符串
; Current version of the time zone data as defined by the ; publisher MEMBER version "version" : STRING
; 由定义的时区数据的当前版本；发布者成员版本“version”：字符串
; An array that lists the set of time zone aliases available ; for the corresponding time zone MEMBER aliases "aliases" : ARRAY STRING
; 列出可用时区别名集的数组；对于相应的时区成员别名“别名”：数组字符串
; An array that lists the set of localized names available ; for the corresponding time zone MEMBER local_names "local-names" : ARRAY OBJECT ( lname, lang, ?pref )
; 列出可用本地化名称集的数组；对于对应的时区成员local_name“local names”：数组对象（lname、lang、？pref）
; Language tag for the language of the associated name MEMBER: lang "lang" : STRING
; 关联名称成员语言的语言标记：lang“lang”：STRING
; Localized name MEMBER lname "name" : STRING
; 本地化名称成员lname“name”：字符串
; Indicates whether this is the preferred name for the associated ; language default: false MEMBER pref "pref" : BOOLEAN
; 指示此名称是否为关联对象的首选名称；语言默认值：false成员pref“pref”：布尔值
Below are the rules for the JSON document returned for a "expand" action request.
下面是为“展开”操作请求返回的JSON文档的规则。
; root object OBJECT ( tzid, ?start, ?end, observances )
; 根对象对象（tzid、开始、结束、观察）
; Time zone identifier MEMBER tzid "tzid" : STRING
; 时区标识符成员tzid“tzid”：字符串
; The actual inclusive start point for the returned observances ; if different from the value of the "start" URI query parameter MEMBER start "start" : STRING
; 返回的观测值的实际包含起点；如果与“start”URI查询参数成员start“start”的值不同：STRING
; The actual exclusive end point for the returned observances ; if different from the value of the "end" URI query parameter MEMBER end "end" : STRING
; 返回的观测的实际排他终点；如果与“end”URI查询参数成员end“end”的值不同：STRING
; Array of time zone objects MEMBER observances "observances" : ARRAY OBJECT ( oname, ?olocal_names, onset, utc_offset_from, utc_offset_to )
; 时区对象数组成员观测值“观测值”：数组对象（oname、olocal名称、起始、utc偏移距、utc偏移距）
; Observance name MEMBER oname "name" : STRING
; 名称成员名称“name”：字符串
; Array of localized observance names MEMBER olocal_names "local-names" : ARRAY STRING
; 本地化名称数组成员本地名称“本地名称”：数组字符串
; UTC date-time value (per [RFC3339]) at which the observance takes ; effect MEMBER onset "onset" : STRING
; 遵守的UTC日期时间值（根据[RFC3339]）；影响成员开始“开始”：字符串
; The UTC offset in seconds before the start of this observance MEMBER utc_offset_from "utc-offset-from" : NUMBER
; 本次活动开始前的UTC偏移量（秒）成员UTC_offset_from“UTC offset from”：编号
; The UTC offset in seconds at and after the start of this observance MEMBER utc_offset_to "utc-offset-to" : NUMBER
; 本次活动开始时及之后的UTC偏移量（以秒为单位）UTC_offset_至“UTC offset to”：编号
Below are the rules for the JSON document returned for a "leapseconds" action request.
下面是为“leapseconds”操作请求返回的JSON文档的规则。
; root object OBJECT ( expires, publisher, version, leapseconds )
; 根对象对象（过期、发布者、版本、秒）
; Last valid date covered by the data in this response ; full-date value as specified in [RFC3339] MEMBER expires "expires" : STRING
; 本回复中数据涵盖的最后有效日期；[RFC3339]成员expires“expires”中指定的完整日期值：字符串
; Leap-second information publisher MEMBER publisher "publisher" : STRING
; 闰秒信息发布者成员发布者“发布者”：字符串
; Current version of the leap-second information as defined by the ; publisher MEMBER version "version" : STRING
; 由定义的闰秒信息的当前版本；发布者成员版本“version”：字符串
; Array of leap-second objects MEMBER leapseconds "leapseconds" : ARRAY OBJECT ( utc_offset, onset )
; 闰秒对象数组成员leapseconds“leapseconds”：数组对象（utc_偏移，起始）
; The UTC offset from TAI in seconds in effect at and after the ; specified date MEMBER utc_offset "utc-offset" : NUMBER
; 与TAI的UTC偏移量，以秒为单位，在；指定日期成员utc_偏移量“utc偏移量”：编号
; full-date value (per [RFC3339]) at which the new UTC offset takes
; effect, at T00:00:00Z
MEMBER onset "onset" : STRING
; full-date value (per [RFC3339]) at which the new UTC offset takes
; effect, at T00:00:00Z
MEMBER onset "onset" : STRING
Property Name: TZUNTIL
属性名称：TZTILL
Purpose: This property specifies an upper bound for the validity period of data within a "VTIMEZONE" component.
用途：此属性指定“VTIMEZONE”组件中数据有效期的上限。
Value Type: DATE-TIME
值类型：日期时间
Property Parameters: IANA and non-standard property parameters can be specified on this property.
属性参数：可以在此属性上指定IANA和非标准属性参数。
Conformance: This property can be specified zero times or one time within "VTIMEZONE" calendar components.
一致性：此属性可以在“VTIMEZONE”日历组件中指定零次或一次。
Description: The value MUST be specified in the UTC time format.
说明：必须以UTC时间格式指定该值。
Time zone data in a "VTIMEZONE" component might cover only a fixed period of time. The start of such a period is clearly indicated by the earliest observance defined by the "STANDARD" and "DAYLIGHT" subcomponents. However, an upper bound on the validity period of the time zone data cannot be simply derived from the observance with the latest onset time, and [RFC5545] does not define a way to get such an upper bound. This specification introduces the "TZUNTIL" property for that purpose. It specifies an "exclusive" UTC date-time value that indicates the last time at which the time zone data is to be considered valid.
“VTIMEZONE”组件中的时区数据可能只覆盖固定的时间段。“标准”和“日光”子组件定义的最早遵守情况清楚地表明了这一时期的开始。然而，时区数据有效期的上限不能简单地从最新开始时间的观测中得出，并且[RFC5545]没有定义获得此类上限的方法。本规范为此引入了“TZTILL”属性。它指定一个“独占”UTC日期时间值，该值指示时区数据最后一次被视为有效的时间。
This property is also used by time zone data distribution servers to indicate the truncation range end point of time zone data (as described in Section 3.9).
时区数据分发服务器也使用此属性来指示时区数据的截断范围端点（如第3.9节所述）。
Format Definition: This property is defined by the following notation in ABNF [RFC5234]:
格式定义：此属性由ABNF[RFC5234]中的以下符号定义：
tzuntil = "TZUNTIL" tzuntilparam ":" date-time CRLF
tzuntil=“tzuntil”tzuntilpram:“日期时间CRLF”
tzuntilparam = *(";" other-param)
tzuntilparam = *(";" other-param)
Example: Suppose a time zone based on astronomical observations has well-defined onset times through the year 2025, but the first onset in 2026 is currently known only approximately. In that case, the "TZUNTIL" property could be specified as follows:
例如：假设一个基于天文观测的时区在2025年有明确的开始时间，但2026年的第一次开始时间目前只知道大约。在这种情况下，“TZTILL”属性可以指定如下：
TZUNTIL:20260101T000000Z
TZUNTIL:20260101T000000Z
Property Name: TZID-ALIAS-OF
属性名称：TZID-ALIAS-OF
Purpose: This property specifies a time zone identifier for which the main time zone identifier is an alias.
用途：此属性指定主时区标识符为别名的时区标识符。
Value Type: TEXT
值类型：文本
Property Parameters: IANA and non-standard property parameters can be specified on this property.
属性参数：可以在此属性上指定IANA和非标准属性参数。
Conformance: This property can be specified zero or more times within "VTIMEZONE" calendar components.
一致性：此属性可以在“VTIMEZONE”日历组件中指定零次或多次。
Description: When the "VTIMEZONE" component uses a time zone identifier alias for the "TZID" property value, the "TZID-ALIAS-OF" property is used to indicate the time zone identifier of the other time zone (see Section 3.7).
描述：“VTIMEZONE”组件将时区标识符别名用于“TZID”属性值时，“TZID-alias-OF”属性用于指示其他时区的时区标识符（请参见第3.7节）。
Format Definition: This property is defined by the following notation in ABNF [RFC5234]:
格式定义：此属性由ABNF[RFC5234]中的以下符号定义：
tzid-alias-of = "TZID-ALIAS-OF" tzidaliasofparam ":" [tzidprefix] text CRLF
tzid alias of=“tzid-alias-of”tzidaliasofparam”：“[tzidprefix]文本CRLF
tzidaliasofparam = *(";" other-param)
tzidaliasofparam = *(";" other-param)
;tzidprefix defined in [RFC5545].
;[RFC5545]中定义的tzidprefix。
Example: The following is an example of this property:
示例：以下是此属性的示例：
TZID-ALIAS-OF:America/New_York
TZID-ALIAS-OF:美国/纽约
Time zone data is critical in determining local or UTC time for devices and in calendaring and scheduling operations. As such, it is vital that a reliable source of time zone data is used. Servers providing a time zone data distribution service MUST support HTTP over Transport Layer Security (TLS) (as defined by [RFC2818] and [RFC5246], with best practices described in [RFC7525]). Servers MAY support a time zone data distribution service over HTTP without TLS. However, secondary servers MUST use TLS to fetch data from a primary server.
时区数据对于确定设备的本地或UTC时间以及日历和日程安排操作至关重要。因此，使用可靠的时区数据源至关重要。提供时区数据分发服务的服务器必须支持传输层安全性（TLS）上的HTTP（如[RFC2818]和[RFC5246]所定义，最佳实践如[RFC7525]所述）。服务器可以支持通过HTTP的时区数据分发服务，而无需TLS。但是，辅助服务器必须使用TLS从主服务器获取数据。
Clients SHOULD use Transport Layer Security as defined by [RFC2818], unless they are specifically configured otherwise. Clients that have been configured to use the TLS-based service MUST NOT fall back to using the non-TLS service if the TLS-based service is not available. In addition, clients MUST NOT follow HTTP redirect requests from a TLS service to a non-TLS service. When using TLS, clients MUST verify the identity of the server, using a standard, secure mechanism such as the certificate verification process specified in [RFC6125] or DANE [RFC6698].
客户机应使用[RFC2818]定义的传输层安全性，除非另有专门配置。如果基于TLS的服务不可用，则已配置为使用基于TLS的服务的客户端不得退回到使用非TLS服务。此外，客户端不得跟踪从TLS服务到非TLS服务的HTTP重定向请求。使用TLS时，客户端必须使用标准的安全机制（如[RFC6125]或DANE[RFC6698]中指定的证书验证过程）验证服务器的身份。
A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause clients to connect to any server chosen by the attacker. In the absence of a secure DNS option, clients SHOULD check that the target FQDN returned in the SRV record is the same as the original service domain that was queried, or is a sub-domain of the original service domain. In many cases, the client configuration is likely to be handled automatically without any user input; as such, any mismatch between the original service domain and the target FQDN is treated as a failure and the client MUST NOT attempt to connect to the target server. In addition, when Transport Layer Security is being used, the Transport Layer Security certificate SHOULD include an SRV-ID field as per [RFC4985] matching the expected DNS SRV queries clients will use for service discovery. If an SRV-ID field is present in a certificate, clients MUST match the SRV-ID value with the service type and domain that matches the DNS SRV request made by the client to discover the service.
具有DNS服务器数据访问权限的恶意攻击者，或能够获取缓存在递归解析程序中的伪造答案的恶意攻击者，可能会导致客户端连接到攻击者选择的任何服务器。在缺少安全DNS选项的情况下，客户端应检查SRV记录中返回的目标FQDN是否与查询的原始服务域相同，或者是否是原始服务域的子域。在许多情况下，客户端配置可能会在没有任何用户输入的情况下自动处理；因此，原始服务域和目标FQDN之间的任何不匹配都将被视为失败，客户端不得尝试连接到目标服务器。此外，当使用传输层安全性时，传输层安全证书应包括符合[RFC4985]的SRV-ID字段，该字段与客户端将用于服务发现的预期DNS SRV查询相匹配。如果证书中存在SRV-ID字段，则客户端必须将SRV-ID值与服务类型和域相匹配，该服务类型和域与客户端为发现服务而发出的DNS SRV请求相匹配。
Time zone data servers SHOULD protect themselves against poorly implemented or malicious clients by throttling high request rates or frequent requests for large amounts of data. Clients can avoid being throttled by using the polling capabilities outlined in Section 4.1.4. Servers MAY require some form of authentication or authorization of clients (including secondary servers), as per [RFC7235], to restrict which clients are allowed to access their service or provide better identification of problematic clients.
时区数据服务器应通过限制高请求率或频繁请求大量数据来保护自己，以防实施不当或恶意客户端。通过使用第4.1.4节中概述的轮询功能，客户端可以避免受到限制。根据[RFC7235]，服务器可能需要对客户端（包括辅助服务器）进行某种形式的身份验证或授权，以限制允许哪些客户端访问其服务或更好地识别有问题的客户端。
The type and pattern of requests that a client makes can be used to "fingerprint" specific clients or devices and thus potentially used to track information about what the users of the clients might be doing. In particular, a client that only downloads time zone data on an as-needed basis, will leak the fact that a user's device has moved from one time zone to another or that the user is receiving scheduling messages from another user in a different time zone.
客户机发出的请求的类型和模式可用于“指纹”特定客户机或设备，因此可能用于跟踪有关客户机用户可能正在做什么的信息。特别是，仅根据需要下载时区数据的客户端将泄漏以下事实：用户的设备已从一个时区移动到另一个时区，或者用户正在从不同时区的另一用户接收调度消息。
Clients need to be aware of the potential ways in which an untrusted server or a network observer might be able to track them and take precautions such as the following:
客户机需要了解不受信任的服务器或网络观察员跟踪他们的潜在方式，并采取以下预防措施：
1. Always use TLS to connect to the server.
1. 始终使用TLS连接到服务器。
2. Avoid use of TLS session resumption.
2. 避免使用TLS会话恢复。
3. Always fetch and synchronize the entire set of time zone data to avoid leaking information about which time zones are actually in use by the client.
3. 始终获取并同步整个时区数据集，以避免泄漏有关客户端实际使用的时区的信息。
4. Randomize the order in which individual time zones are fetched using the "get" action, when retrieving a set of time zones based on a "list" action response.
4. 根据“列表”操作响应检索一组时区时，使用“获取”操作随机获取各个时区的顺序。
5. Avoid use of conditional HTTP requests [RFC7232] with the "get" action to prevent tracking of clients by servers generating client-specific ETag header field values.
5. 避免将条件HTTP请求[RFC7232]与“get”操作一起使用，以防止服务器生成特定于客户端的ETag头字段值来跟踪客户端。
6. Avoid use of cookies in HTTP requests [RFC6265].
6. 避免在HTTP请求中使用Cookie[RFC6265]。
7. Avoid use of authenticated HTTP requests.
7. 避免使用经过身份验证的HTTP请求。
8. When doing periodic polling to check for updates, apply a random (positive or negative) offset to the next poll time to avoid servers being able to identify the client by the specific periodicity of its polling behavior.
8. 在执行定期轮询以检查更新时，对下一次轮询时间应用随机（正或负）偏移量，以避免服务器能够通过其轮询行为的特定周期来识别客户端。
9. A server trying to "fingerprint" clients might insert a "fake" time zone into the time zone data, using a unique identifier for each client making a request. The server can then watch for client requests that refer to that "fake" time zone and thus track the activity of each client. It is hard for clients to identify a "fake" time zone given that new time zones are added occasionally. One option to mitigate this would be for the client to make use of two time zone data distribution servers from two independent providers that provide time zone data from
9. 试图“指纹”客户端的服务器可能会在时区数据中插入一个“假”时区，为每个发出请求的客户端使用一个唯一的标识符。然后，服务器可以监视引用该“假”时区的客户端请求，从而跟踪每个客户端的活动。考虑到偶尔会添加新时区，客户很难识别“假”时区。缓解这种情况的一种选择是，客户机使用来自两个独立提供商的两个时区数据分发服务器，这两个提供商从
the same publisher. The client can then compare the list of time zones from each server (assuming they both have the same version of time zone data from the common publisher) and detect ones that appear to be added on one server and not the other. Alternatively, the client can check the publisher data directly to verify that time zones match the set the publisher has.
同一个出版商。然后，客户端可以比较每台服务器的时区列表（假设它们都具有来自公共发布服务器的相同版本的时区数据），并检测似乎添加到一台服务器而不是另一台服务器上的时区。或者，客户端可以直接检查发布服务器数据，以验证时区是否与发布服务器的设置相匹配。
Note that some of the above recommendations will result in less efficient use of the protocol due to fetching data that might not be relevant to the client.
请注意，由于获取可能与客户端无关的数据，上述一些建议将导致协议的使用效率降低。
An organization can set up a secondary server within their own domain and configure their clients to use that server to protect the organization's users from the possibility of being tracked by an untrusted time zone data distribution server. Clients can then use more-efficient protocol interactions, free from the concerns above, on the basis that their organization's server is trusted. When doing this, the secondary server would follow the recommendations for clients (listed in the previous paragraph) so that the untrusted server is not able to gain information about the organization as a whole. Note, however, that client requests to the secondary server are subject to tracking by a network observer, so clients ought to apply some of the randomization techniques from the list above.
组织可以在其自己的域内设置辅助服务器，并将其客户端配置为使用该服务器，以保护组织的用户不受不受信任的时区数据分发服务器的跟踪。然后，客户机可以在其组织的服务器受信任的基础上，使用更高效的协议交互，而不必考虑上述问题。执行此操作时，辅助服务器将遵循针对客户端的建议（在上一段中列出），因此不受信任的服务器无法获得有关整个组织的信息。但是，请注意，客户端对辅助服务器的请求会受到网络观察者的跟踪，因此客户端应该应用上面列表中的一些随机化技术。
Servers that want to avoid accidentally storing information that could be used to identify clients can take the following precautions:
希望避免意外存储可用于识别客户端的信息的服务器可以采取以下预防措施：
1. Avoid logging client request activity, or anonymize information in any logs (e.g., client IP address, client user-agent details, authentication credentials, etc.).
1. 避免记录客户端请求活动，或匿名化任何日志中的信息（例如，客户端IP地址、客户端用户代理详细信息、身份验证凭据等）。
2. Add an unused HTTP response header to each response with a random amount of data in it (e.g., to pad the overall request size to the nearest power-of-2 or 128-byte boundary) to avoid exposing which time zones are being fetched when TLS is being used, via network traffic analysis.
2. 在每个响应中添加一个未使用的HTTP响应头，其中包含随机数量的数据（例如，将总请求大小填充到最近的2次幂或128字节边界），以避免通过网络流量分析暴露使用TLS时提取的时区。
This specification defines a new registry of "actions" for the time zone data distribution service protocol, defines a "well-known" URI using the registration procedure and template from Section 5.1 of [RFC5785], creates two new SRV service label aliases, and defines one new iCalendar property parameter as per the registration procedure in [RFC5545]. It also adds a new "TZDIST Identifiers Registry" to the IETF parameters URN sub-namespace as per [RFC3553] for use with protocol related error codes.
本规范为时区数据分发服务协议定义了一个新的“操作”注册表，使用[RFC5785]第5.1节中的注册过程和模板定义了一个“已知”URI，创建了两个新的SRV服务标签别名，并根据中的注册过程定义了一个新的iCalendar属性参数[RFC5545]。它还根据[RFC3553]向IETF参数URN子命名空间添加了一个新的“TZDIST标识符注册表”，用于协议相关错误代码。
IANA has created a new top-level category called "Time Zone Data Distribution Service (TZDIST) Parameters" and has put all the registries created herein into that category.
IANA创建了一个名为“时区数据分发服务（TZDIST）参数”的新的顶级类别，并将此处创建的所有注册表都归入该类别。
IANA has created a new registry called "TZDIST Service Actions", as defined below.
IANA创建了一个名为“TZDIST服务操作”的新注册表，定义如下。
This registry uses the "Specification Required" policy defined in [RFC5226], which makes use of a designated expert to review potential registrations.
该注册中心使用[RFC5226]中定义的“所需规范”策略，该策略利用指定专家审查潜在注册。
The IETF has created a mailing list, tzdist-service@ietf.org, which is used for public discussion of time zone data distribution service actions proposals prior to registration. The IESG has appointed a designated expert who will monitor the tzdist-service@ietf.org mailing list and review registrations.
IETF已经创建了一个邮件列表tzdist-service@ietf.org，用于在注册前公开讨论时区数据分发服务行动建议。IESG已指定一名专家，负责监督tzdist-service@ietf.org邮件列表和审查注册。
A Standards Track RFC is REQUIRED for changes to actions previously documented in a Standards Track RFC; otherwise, any public specification that satisfies the requirements of [RFC5226] is acceptable.
对于之前记录在标准跟踪RFC中的行动的变更，需要标准跟踪RFC；否则，满足[RFC5226]要求的任何公共规范均可接受。
The registration procedure begins when a completed registration template, as defined below, is sent to tzdist-service@ietf.org and iana@iana.org. The designated expert is expected to tell IANA and the submitter of the registration whether the registration is approved, approved with minor changes, or rejected with cause, within two weeks. When a registration is rejected with cause, it can be resubmitted if the concerns listed in the cause are addressed. Decisions made by the designated expert can be appealed as per Section 7 of [RFC5226].
当完成的注册模板（定义如下）发送到tzdist时，注册过程开始-service@ietf.org和iana@iana.org. 指定专家应在两周内告知IANA和注册提交人该注册是否被批准、批准时有微小变更，还是有理由被拒绝。当注册因原因被拒绝时，如果原因中列出的问题得到解决，则可以重新提交注册。指定专家做出的决定可根据[RFC5226]第7节提出上诉。
The designated expert MUST take the following requirements into account when reviewing the registration:
指定专家在审查注册时必须考虑以下要求：
1. A valid registration template MUST be provided by the submitter, with a clear description of what the action does.
1. 提交者必须提供一个有效的注册模板，并清楚地说明该操作的作用。
2. A proposed new action name MUST NOT conflict with any existing registered action name. A conflict includes a name that duplicates an existing one or that appears to be very similar to an existing one and could be a potential source of confusion.
2. 建议的新操作名称不得与任何现有注册的操作名称冲突。冲突包括与现有名称重复的名称或与现有名称非常相似的名称，可能会造成混淆。
3. A proposed new action MUST NOT exactly duplicate the functionality of any existing actions. In cases where the new action functionality is very close to an existing action, the designated expert SHOULD clarify whether the submitter is aware of the existing action, and has an adequate reason for creating a new action with slight differences from an existing one.
3. 提议的新操作不得完全复制任何现有操作的功能。如果新行动功能与现有行动非常接近，指定专家应澄清提交人是否知道现有行动，并有充分理由创建与现有行动略有不同的新行动。
4. If a proposed action is an extension to an existing action, the changes MUST NOT conflict with the intent of the existing action, or in a way that could cause interoperability problems for existing deployments of the protocol.
4. 如果提议的操作是现有操作的扩展，则更改不得与现有操作的意图冲突，或以可能导致协议现有部署的互操作性问题的方式冲突。
The IANA registry contains the name of the action ("Action Name") and a reference to the section of the specification where the action registration template is defined ("Reference").
IANA注册表包含操作的名称（“操作名称”）和对定义操作注册模板的规范部分的引用（“引用”）。
An action is defined by completing the following template.
通过完成以下模板定义操作。
Name: The name of the action.
名称：操作的名称。
Request-URI Template: The URI template used in HTTP requests for the action.
请求URI模板：操作的HTTP请求中使用的URI模板。
Description: A general description of the action, its purpose, etc.
描述：对行动、目的等的一般描述。
Parameters: A list of allowed request URI query parameters, indicating whether they are "REQUIRED" or "OPTIONAL" and whether they can occur only once or multiple times, together with the expected format of the parameter values.
参数：允许的请求URI查询参数列表，指示它们是“必需的”还是“可选的”，以及它们是否只能出现一次或多次，以及参数值的预期格式。
Response: The nature of the response to the HTTP request, e.g., what format the response data is in.
响应：HTTP请求响应的性质，例如响应数据的格式。
Possible Error Codes: Possible error codes reported in a JSON "problem details" object if an HTTP request fails.
可能的错误代码：如果HTTP请求失败，JSON“问题详细信息”对象中可能报告的错误代码。
The following table provides the initial content of the actions registry.
下表提供了操作注册表的初始内容。
+---------------+------------------------+
| Action Name | Reference |
+---------------+------------------------+
| capabilities | RFC 7808, Section 5.1 |
| list | RFC 7808, Section 5.2 |
| get | RFC 7808, Section 5.3 |
| expand | RFC 7808, Section 5.4 |
| find | RFC 7808, Section 5.5 |
| leapseconds | RFC 7808, Section 5.6 |
+---------------+------------------------+
+---------------+------------------------+
| Action Name | Reference |
+---------------+------------------------+
| capabilities | RFC 7808, Section 5.1 |
| list | RFC 7808, Section 5.2 |
| get | RFC 7808, Section 5.3 |
| expand | RFC 7808, Section 5.4 |
| find | RFC 7808, Section 5.5 |
| leapseconds | RFC 7808, Section 5.6 |
+---------------+------------------------+
IANA has added the following to the "Well-Known URIs" [RFC5785] registry:
IANA已将以下内容添加到“知名URI”[RFC5785]注册表中：
URI suffix: timezone
URI后缀：时区
Change controller: IESG.
更改控制器：IESG。
Specification document(s): RFC 7808
规范文件：RFC 7808
Related information: None.
相关信息：无。
IANA has added two new service names to the "Service Name and Transport Protocol Port Number Registry" [RFC6335], as defined below.
IANA向“服务名称和传输协议端口号注册表”[RFC6335]添加了两个新的服务名称，定义如下。
Service Name: timezone
服务名称：时区
Transport Protocol(s): TCP
传输协议：TCP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Time Zone Data Distribution Service - non-TLS
描述：时区数据分发服务-非TLS
Reference: RFC 7808
参考：RFC 7808
Assignment Note: This is an extension of the http service. Defined TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
分配说明：这是http服务的扩展。定义的TXT键：路径=<context path>（根据[RFC6763]第6节）。
Service Name: timezones
服务名称：时区
Transport Protocol(s): TCP
传输协议：TCP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Contact: IETF Chair <chair@ietf.org>
Description: Time Zone Data Distribution Service - over TLS
描述：时区数据分发服务-通过TLS
Reference: RFC 7808
参考：RFC 7808
Assignment Note: This is an extension of the https service. Defined TXT keys: path=<context path> (as per Section 6 of [RFC6763]).
分配说明：这是https服务的扩展。定义的TXT键：路径=<context path>（根据[RFC6763]第6节）。
IANA has registered a new URN sub-namespace within the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers defined in [RFC3553].
IANA已在IETF URN子命名空间中注册了一个新的URN子命名空间，用于[RFC3553]中定义的已注册协议参数标识符。
Registrations in this registry follow the "IETF Review" [RFC5226] policy.
此注册表中的注册遵循“IETF审查”[RFC5226]政策。
Registry name: TZDIST Identifiers
注册表名：TZDIST标识符
URN prefix: urn:ietf:params:tzdist
URN prefix: urn:ietf:params:tzdist
Specification: RFC 7808
规格：RFC7808
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Index value: Values in this registry are URNs or URN prefixes that start with the prefix "urn:ietf:params:tzdist:". Each is registered independently. The prefix "urn:ietf:params:tzdist:error:" is used to represent specific error codes within the protocol as defined in the list of actions in Section 5 and used in problem reports (Section 4.1.7).
索引值：此注册表中的值是以前缀“URN:ietf:params:tzdist:”开头的URN或URN前缀。每个都是独立注册的。前缀“urn:ietf:params:tzdist:error:”用于表示协议中的特定错误代码，如第5节中的操作列表所定义，并用于问题报告（第4.1.7节）。
Each registration in the "TZDIST Identifiers" registry requires the following information:
“TZDIST标识符”注册表中的每个注册都需要以下信息：
URN: The complete URN that is used or the prefix for that URN.
URN：使用的完整URN或该URN的前缀。
Description: A summary description for the URN or URN prefix.
描述：URN或URN前缀的摘要描述。
Specification: A reference to a specification describing the URN or URN prefix.
规范：对描述URN或URN前缀的规范的引用。
Contact: Email for the person or groups making the registration.
联系人：进行注册的个人或团体的电子邮件。
Index Value: As described in [RFC3553], URN prefixes that are registered include a description of how the URN is constructed. This is not applicable for specific URNs.
索引值：如[RFC3553]中所述，注册的URN前缀包括URN构造方式的说明。这不适用于特定的骨灰盒。
The "TZDIST Identifiers" registry has the initial registrations included in the following sections.
“TZDIST标识符”注册表的初始注册包含在以下部分中。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:invalid-action
URN: urn:ietf:params:tzdist:error:invalid-action
Description: Generic error code for any invalid action.
描述：任何无效操作的通用错误代码。
Specification: RFC 7808, Section 5
规范：RFC 7808，第5节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:invalid-changedsince
URN: urn:ietf:params:tzdist:error:invalid-changedsince
Description: Error code for incorrect use of the "changedsince" URI query parameter.
描述：错误使用“changedsince”URI查询参数的错误代码。
Specification: RFC 7808, Section 5.2
规范：RFC 7808，第5.2节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:tzid-not-found
URN: urn:ietf:params:tzdist:error:tzid-not-found
Description: Error code for missing time zone identifier.
描述：缺少时区标识符的错误代码。
Specification: RFC 7808, Sections 5.3 and 5.4
规范：RFC 7808，第5.3节和第5.4节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:invalid-format
URN: urn:ietf:params:tzdist:error:invalid-format
Description: Error code for unsupported HTTP Accept request header field value.
描述：不支持的HTTP接受请求标头字段值的错误代码。
Specification: RFC 7808, Section 5.3
规范：RFC 7808，第5.3节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:invalid-start
URN: urn:ietf:params:tzdist:error:invalid-start
Description: Error code for incorrect use of the "start" URI query parameter.
描述：错误使用“开始”URI查询参数的错误代码。
Specification: RFC 7808, Sections 5.3 and 5.4
规范：RFC 7808，第5.3节和第5.4节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:invalid-end
URN: urn:ietf:params:tzdist:error:invalid-end
Description: Error code for incorrect use of the "end" URI query parameter.
描述：错误使用“end”URI查询参数的错误代码。
Specification: RFC 7808, Sections 5.3 and 5.4
规范：RFC 7808，第5.3节和第5.4节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
The following URN has been registered in the "tzdist Identifiers" registry.
以下URN已在“tzdist标识符”注册表中注册。
URN: urn:ietf:params:tzdist:error:invalid-pattern
URN: urn:ietf:params:tzdist:error:invalid-pattern
Description: Error code for incorrect use of the "pattern" URI query parameter.
描述：错误使用“模式”URI查询参数的错误代码。
Specification: RFC 7808, Section 5.5
规范：RFC 7808，第5.5节
Repository: http://www.iana.org/assignments/tzdist-identifiers
Repository: http://www.iana.org/assignments/tzdist-identifiers
Contact: IESG <iesg@ietf.org>
Contact: IESG <iesg@ietf.org>
Index value: N/A.
指标值：不适用。
This document defines the following new iCalendar properties, which have been added to the "Properties" registry under "iCalendar Element Registries" [RFC5545]:
本文档定义了以下新的iCalendar属性，这些属性已添加到“iCalendar元素注册表”下的“属性”注册表[RFC5545]：
+----------------+----------+------------------------+
| Property | Status | Reference |
+----------------+----------+------------------------+
| TZUNTIL | Current | RFC 7808, Section 7.1 |
| TZID-ALIAS-OF | Current | RFC 7808, Section 7.2 |
+----------------+----------+------------------------+
+----------------+----------+------------------------+
| Property | Status | Reference |
+----------------+----------+------------------------+
| TZUNTIL | Current | RFC 7808, Section 7.1 |
| TZID-ALIAS-OF | Current | RFC 7808, Section 7.2 |
+----------------+----------+------------------------+
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<http://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<http://www.rfc-editor.org/info/rfc2782>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<http://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3553]Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子命名空间”，BCP 73，RFC 3553，DOI 10.17487/RFC3553，2003年6月<http://www.rfc-editor.org/info/rfc3553>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, <http://www.rfc-editor.org/info/rfc4985>.
[RFC4985]Santesson，S.，“互联网X.509公钥基础设施主体服务名称表达的备选名称”，RFC 4985，DOI 10.17487/RFC4985，2007年8月<http://www.rfc-editor.org/info/rfc4985>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5545] Desruisseaux, B., Ed., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, DOI 10.17487/RFC5545, September 2009, <http://www.rfc-editor.org/info/rfc5545>.
[RFC5545]Desruisseaux，B.，Ed.“互联网日历和调度核心对象规范（iCalendar）”，RFC 5545，DOI 10.17487/RFC5545，2009年9月<http://www.rfc-editor.org/info/rfc5545>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]诺丁汉，M.和E.Hammer Lahav，“定义众所周知的统一资源标识符（URI）”，RFC 5785，DOI 10.17487/RFC5785，2010年4月<http://www.rfc-editor.org/info/rfc5785>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC 6265，DOI 10.17487/RFC6265，2011年4月<http://www.rfc-editor.org/info/rfc6265>.
[RFC6321] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML Format for iCalendar", RFC 6321, DOI 10.17487/RFC6321, August 2011, <http://www.rfc-editor.org/info/rfc6321>.
[RFC6321]Daboo，C.，Douglass，M.，和S.Lees，“xCal：iCalendar的XML格式”，RFC 6321DOI 10.17487/RFC6321，2011年8月<http://www.rfc-editor.org/info/rfc6321>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<http://www.rfc-editor.org/info/rfc6335>.
[RFC6557] Lear, E. and P. Eggert, "Procedures for Maintaining the Time Zone Database", BCP 175, RFC 6557, DOI 10.17487/RFC6557, February 2012, <http://www.rfc-editor.org/info/rfc6557>.
[RFC6557]Lear，E.和P.Eggert，“时区数据库维护程序”，BCP 175，RFC 6557，DOI 10.17487/RFC6557，2012年2月<http://www.rfc-editor.org/info/rfc6557>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <http://www.rfc-editor.org/info/rfc6570>.
[RFC6570]Gregorio，J.，Fielding，R.，Hadley，M.，Nottingham，M.，和D.Orchard，“URI模板”，RFC 6570，DOI 10.17487/RFC657012年3月<http://www.rfc-editor.org/info/rfc6570>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<http://www.rfc-editor.org/info/rfc6763>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7265] Kewisch, P., Daboo, C., and M. Douglass, "jCal: The JSON Format for iCalendar", RFC 7265, DOI 10.17487/RFC7265, May 2014, <http://www.rfc-editor.org/info/rfc7265>.
[RFC7265]Kewisch，P.，Daboo，C.，和M.Douglass，“jCal：iCalendar的JSON格式”，RFC 7265，DOI 10.17487/RFC7265，2014年5月<http://www.rfc-editor.org/info/rfc7265>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <http://www.rfc-editor.org/info/rfc7807>.
[RFC7807]诺丁汉，M.和E.王尔德，“HTTP API的问题细节”，RFC 7807，DOI 10.17487/RFC7807，2016年3月<http://www.rfc-editor.org/info/rfc7807>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
Acknowledgements
致谢
The authors would like to thank the members of the Calendaring and Scheduling Consortium's Time Zone Technical Committee, and the participants and chairs of the IETF tzdist working group. In particular, the following individuals have made important contributions to this work: Steve Allen, Lester Caine, Stephen Colebourne, Tobias Conradi, Steve Crocker, Paul Eggert, Daniel Kahn Gillmor, John Haug, Ciny Joy, Bryan Keller, Barry Leiba, Andrew McMillan, Ken Murchison, Tim Parenti, Arnaud Quillaud, Jose Edvaldo Saraiva, and Dave Thewlis.
作者要感谢日历和日程安排协会时区技术委员会的成员，以及IETF tzdist工作组的参与者和主席。特别是，以下个人对这项工作做出了重要贡献：史蒂夫·艾伦、莱斯特·凯恩、斯蒂芬·科尔伯恩、托比亚斯·康拉迪、史蒂夫·克罗克、保罗·艾格特、丹尼尔·卡恩·吉尔莫、约翰·豪格、辛尼·乔伊、布莱恩·凯勒、巴里·莱巴、安德鲁·麦克米兰、肯·默奇森、蒂姆·帕雷蒂、阿诺·基劳德、何塞·埃德瓦尔多·萨拉瓦、，戴夫·特维斯。
This specification originated from work at the Calendaring and Scheduling Consortium, which has supported the development and testing of implementations of the specification.
本规范源于日历和调度联盟的工作，该联盟支持规范实现的开发和测试。
Authors' Addresses
作者地址
Michael Douglass Spherical Cow Group 226 3rd Street Troy, NY 12180 United States
美国纽约州特洛伊市第三街226号迈克尔·道格拉斯集团，邮编：12180
Email: mdouglass@sphericalcowgroup.com
URI: http://sphericalcowgroup.com
Email: mdouglass@sphericalcowgroup.com
URI: http://sphericalcowgroup.com
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 United States
Cyrus Daboo苹果公司，美国加利福尼亚州库比蒂诺市无限环路1号，邮编95014
Email: cyrus@daboo.name
URI: http://www.apple.com/
Email: cyrus@daboo.name
URI: http://www.apple.com/