Network Working Group G. Klyne
Request for Comments: 3339 Clearswift Corporation
Category: Standards Track C. Newman
Sun Microsystems
July 2002
Network Working Group G. Klyne
Request for Comments: 3339 Clearswift Corporation
Category: Standards Track C. Newman
Sun Microsystems
July 2002
Date and Time on the Internet: Timestamps
Internet上的日期和时间：时间戳
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
本文件定义了互联网协议中使用的日期和时间格式，该格式是ISO 8601标准的概要，用于使用公历表示日期和时间。
Table of Contents
目录
1. Introduction ............................................ 2
2. Definitions ............................................. 3
3. Two Digit Years ......................................... 4
4. Local Time .............................................. 4
4.1. Coordinated Universal Time (UTC) ...................... 4
4.2. Local Offsets ......................................... 5
4.3. Unknown Local Offset Convention ....................... 5
4.4. Unqualified Local Time ................................ 5
5. Date and Time format .................................... 6
5.1. Ordering .............................................. 6
5.2. Human Readability ..................................... 6
5.3. Rarely Used Options ................................... 7
5.4. Redundant Information ................................. 7
5.5. Simplicity ............................................ 7
5.6. Internet Date/Time Format ............................. 8
5.7. Restrictions .......................................... 9
5.8. Examples ............................................. 10
6. References ............................................. 10
7. Security Considerations ................................ 11
1. Introduction ............................................ 2
2. Definitions ............................................. 3
3. Two Digit Years ......................................... 4
4. Local Time .............................................. 4
4.1. Coordinated Universal Time (UTC) ...................... 4
4.2. Local Offsets ......................................... 5
4.3. Unknown Local Offset Convention ....................... 5
4.4. Unqualified Local Time ................................ 5
5. Date and Time format .................................... 6
5.1. Ordering .............................................. 6
5.2. Human Readability ..................................... 6
5.3. Rarely Used Options ................................... 7
5.4. Redundant Information ................................. 7
5.5. Simplicity ............................................ 7
5.6. Internet Date/Time Format ............................. 8
5.7. Restrictions .......................................... 9
5.8. Examples ............................................. 10
6. References ............................................. 10
7. Security Considerations ................................ 11
Appendix A. ISO 8601 Collected ABNF ....................... 12
Appendix B. Day of the Week ............................... 14
Appendix C. Leap Years .................................... 14
Appendix D. Leap Seconds ..............................,... 15
Acknowledgements .......................................... 17
Authors' Addresses ........................................ 17
Full Copyright Statement .................................. 18
Appendix A. ISO 8601 Collected ABNF ....................... 12
Appendix B. Day of the Week ............................... 14
Appendix C. Leap Years .................................... 14
Appendix D. Leap Seconds ..............................,... 15
Acknowledgements .......................................... 17
Authors' Addresses ........................................ 17
Full Copyright Statement .................................. 18
Date and time formats cause a lot of confusion and interoperability problems on the Internet. This document addresses many of the problems encountered and makes recommendations to improve consistency and interoperability when representing and using date and time in Internet protocols.
日期和时间格式在互联网上造成了许多混乱和互操作性问题。本文档解决了在Internet协议中表示和使用日期和时间时遇到的许多问题，并提出了改进一致性和互操作性的建议。
This document includes an Internet profile of the ISO 8601 [ISO8601] standard for representation of dates and times using the Gregorian calendar.
本文件包括使用公历表示日期和时间的ISO 8601[ISO8601]标准的互联网简介。
There are many ways in which date and time values might appear in Internet protocols: this document focuses on just one common usage, viz. timestamps for Internet protocol events. This limited consideration has the following consequences:
日期和时间值可能以多种方式出现在Internet协议中：本文档只关注一种常见用法，即。Internet协议事件的时间戳。这种有限的考虑会产生以下后果：
o All dates and times are assumed to be in the "current era", somewhere between 0000AD and 9999AD.
o 假设所有日期和时间都在“当前时代”，介于公元0000AD和9999AD之间。
o All times expressed have a stated relationship (offset) to Coordinated Universal Time (UTC). (This is distinct from some usage in scheduling applications where a local time and location may be known, but the actual relationship to UTC may be dependent on the unknown or unknowable actions of politicians or administrators. The UTC time corresponding to 17:00 on 23rd March 2005 in New York may depend on administrative decisions about daylight savings time. This specification steers well clear of such considerations.)
o 表示的所有时间都与协调世界时（UTC）有规定的关系（偏移）。（这与调度应用程序中的某些用法不同，在调度应用程序中，本地时间和位置可能已知，但与UTC的实际关系可能取决于政治家或管理员的未知或不可知行为。纽约2005年3月23日17:00对应的UTC时间可能取决于有关dayligh的管理决定。）t节省时间。本规范完全避免了此类考虑。）
o Timestamps can express times that occurred before the introduction of UTC. Such timestamps are expressed relative to universal time, using the best available practice at the stated time.
o 时间戳可以表示引入UTC之前发生的时间。这种时间戳是相对于世界时间表示的，在规定的时间使用最佳可用实践。
o Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.
o 日期和时间表达式表示时间上的一个瞬间。这里不包括时间段或间隔的描述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
UTC Coordinated Universal Time as maintained by the Bureau International des Poids et Mesures (BIPM).
UTC协调世界时，由国际测量局（BIPM）维护。
second A basic unit of measurement of time in the International System of Units. It is defined as the duration of 9,192,631,770 cycles of microwave light absorbed or emitted by the hyperfine transition of cesium-133 atoms in their ground state undisturbed by external fields.
第二，国际单位制中时间的基本计量单位。它被定义为基态铯133原子在不受外场干扰的情况下通过超精细跃迁吸收或发射的9192631770个微波周期的持续时间。
minute A period of time of 60 seconds. However, see also the restrictions in section 5.7 and Appendix D for how leap seconds are denoted within minutes.
分钟一段60秒的时间。但是，关于如何在分钟内表示闰秒，请参见第5.7节和附录D中的限制。
hour A period of time of 60 minutes.
小时60分钟的一段时间。
day A period of time of 24 hours.
一天24小时的一段时间。
leap year In the Gregorian calendar, a year which has 366 days. A leap year is a year whose number is divisible by four an integral number of times, except that if it is a centennial year (i.e. divisible by one hundred) it shall also be divisible by four hundred an integral number of times.
公历中的闰年，有366天。闰年是一个数字可以被四整除的年份，但如果是百年（即，可以被一百整除），那么它也可以被四百整除。
ABNF Augmented Backus-Naur Form, a format used to represent permissible strings in a protocol or language, as defined in [ABNF].
ABNF扩充的Backus Naur格式，一种用于表示协议或语言中允许的字符串的格式，如[ABNF]中所定义。
Email Date/Time Format The date/time format used by Internet Mail as defined by RFC 2822 [IMAIL-UPDATE].
电子邮件日期/时间格式RFC 2822[IMAIL-UPDATE]定义的Internet邮件使用的日期/时间格式。
Internet Date/Time Format The date format defined in section 5 of this document.
Internet日期/时间格式本文件第5节中定义的日期格式。
Timestamp This term is used in this document to refer to an unambiguous representation of some instant in time.
时间戳这个术语在本文档中用于表示某个时间瞬间的明确表示。
Z A suffix which, when applied to a time, denotes a UTC offset of 00:00; often spoken "Zulu" from the ICAO phonetic alphabet representation of the letter "Z".
Z当应用于时间时，表示UTC偏移量为00:00的后缀；常说的“祖鲁”来自国际民航组织拼音字母表中的字母“Z”。
For more information about time scales, see Appendix E of [NTP], Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF].
有关时间尺度的更多信息，请参见[NTP]附录E、[ISO8601]第3节和适当的ITU文件[ITU-R-TF]。
The following requirements are to address the problems of ambiguity of 2-digit years:
以下要求旨在解决两位数年份的模糊性问题：
o Internet Protocols MUST generate four digit years in dates.
o 互联网协议必须生成四位数的年份。
o The use of 2-digit years is deprecated. If a 2-digit year is received, it should be accepted ONLY if an incorrect interpretation will not cause a protocol or processing failure (e.g. if used only for logging or tracing purposes).
o 不推荐使用两位数的年份。如果收到2位数的年份，只有在错误解释不会导致协议或处理失败（例如，仅用于记录或跟踪目的）的情况下，才应接受该年份。
o It is possible that a program using two digit years will represent years after 1999 as three digits. This occurs if the program simply subtracts 1900 from the year and doesn't check the number of digits. Programs wishing to robustly deal with dates generated by such broken software may add 1900 to three digit years.
o 使用两位数年份的程序可能将1999年之后的年份表示为三位数。如果程序只是从年份中减去1900，而不检查位数，则会发生这种情况。希望稳健地处理这些坏软件生成的日期的程序可能会将1900年增加到三位数。
o It is possible that a program using two digit years will represent years after 1999 as ":0", ":1", ... ":9", ";0", ... This occurs if the program simply subtracts 1900 from the year and adds the decade to the US-ASCII character zero. Programs wishing to robustly deal with dates generated by such broken software should detect non-numeric decades and interpret appropriately.
o 使用两位数年份的程序可能会将1999年之后的年份表示为“：0”、“：1”。。。":9", ";0", ... 如果程序只是从年份中减去1900，然后将十年添加到US-ASCII字符零，则会发生这种情况。希望稳健地处理由这种坏软件生成的日期的程序应该检测非数字的十年，并进行适当的解释。
The problems with two digit years amply demonstrate why all dates and times used in Internet protocols MUST be fully qualified.
两位数年份的问题充分说明了为什么互联网协议中使用的所有日期和时间都必须完全合格。
Because the daylight saving rules for local time zones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC). This specification does not cater to local time zone rules.
由于当地时区的夏令时规则非常复杂，并且在不可预测的时间内可能会根据当地法律发生变化，因此使用协调世界时（UTC）最能实现真正的互操作性。本规范不符合当地时区规则。
The offset between local time and UTC is often useful information. For example, in electronic mail (RFC2822, [IMAIL-UPDATE]) the local offset provides a useful heuristic to determine the probability of a prompt response. Attempts to label local offsets with alphabetic strings have resulted in poor interoperability in the past [IMAIL], [HOST-REQ]. As a result, RFC2822 [IMAIL-UPDATE] has made numeric offsets mandatory.
本地时间和UTC之间的偏移量通常是有用的信息。例如，在电子邮件（RFC2822，[IMAIL-UPDATE]）中，本地偏移量提供了一种有用的启发式方法来确定即时响应的概率。在过去的[IMAIL]、[HOST-REQ]中，尝试用字母字符串标记本地偏移量导致互操作性差。因此，RFC2822[IMAIL-UPDATE]已将数字偏移设置为强制性。
Numeric offsets are calculated as "local time minus UTC". So the equivalent time in UTC can be determined by subtracting the offset from the local time. For example, 18:50:00-04:00 is the same time as 22:50:00Z. (This example shows negative offsets handled by adding the absolute value of the offset.)
数值偏移计算为“本地时间减去UTC”。因此，UTC的等效时间可以通过从本地时间减去偏移量来确定。例如，18:50:00-04:00与22:50:00Z的时间相同。（此示例显示通过添加偏移的绝对值处理的负偏移。）
NOTE: Following ISO 8601, numeric offsets represent only time zones that differ from UTC by an integral number of minutes. However, many historical time zones differ from UTC by a non-integral number of minutes. To represent such historical time stamps exactly, applications must convert them to a representable time zone.
注：按照ISO 8601，数字偏移仅表示与UTC相差整数分钟的时区。但是，许多历史时区与UTC的差异不是整数分钟数。为了准确地表示此类历史时间戳，应用程序必须将其转换为可表示的时区。
If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email.
如果UTC时间已知，但与本地时间的偏移量未知，则可以用“-00:00”偏移量表示。这在语义上不同于偏移量“Z”或“+00:00”，这意味着UTC是指定时间的首选参考点。RFC2822[IMAIL-UPDATE]描述了电子邮件的类似约定。
A number of devices currently connected to the Internet run their internal clocks in local time and are unaware of UTC. While the Internet does have a tradition of accepting reality when creating specifications, this should not be done at the expense of interoperability. Since interpretation of an unqualified local time zone will fail in approximately 23/24 of the globe, the interoperability problems of unqualified local time are deemed unacceptable for the Internet. Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC. Some suitable mechanisms are:
许多当前连接到Internet的设备在本地时间运行其内部时钟，并且不知道UTC。虽然互联网在创建规范时确实有接受现实的传统，但这不应该以牺牲互操作性为代价。由于全球约23/24的地区无法解释不合格的当地时区，因此不合格当地时间的互操作性问题被认为是互联网无法接受的。使用本地时间配置的系统不知道相应的UTC偏移，并且依赖于与其他Internet系统的时间同步，必须使用确保与UTC正确同步的机制。一些合适的机制包括：
o Use Network Time Protocol [NTP] to obtain the time in UTC.
o 使用网络时间协议[NTP]获取UTC时间。
o Use another host in the same local time zone as a gateway to the Internet. This host MUST correct unqualified local times that are transmitted to other hosts.
o 使用同一本地时区中的另一台主机作为Internet网关。此主机必须更正传输到其他主机的非限定本地时间。
o Prompt the user for the local time zone and daylight saving rule settings.
o 提示用户输入本地时区和夏令时规则设置。
This section discusses desirable qualities of date and time formats and defines a profile of ISO 8601 for use in Internet protocols.
本节讨论了日期和时间格式的理想特性，并定义了用于Internet协议的ISO 8601概要。
If date and time components are ordered from least precise to most precise, then a useful property is achieved. Assuming that the time zones of the dates and times are the same (e.g., all in UTC), expressed using the same string (e.g., all "Z" or all "+00:00"), and all times have the same number of fractional second digits, then the date and time strings may be sorted as strings (e.g., using the strcmp() function in C) and a time-ordered sequence will result. The presence of optional punctuation would violate this characteristic.
如果日期和时间组件从最不精确到最精确排序，则会获得有用的属性。假设日期和时间的时区相同（例如，全部以UTC表示），使用相同的字符串表示（例如，全部“Z”或全部“+00:00”），并且所有时间的小数位数相同，则可以将日期和时间字符串排序为字符串（例如，使用C中的strcmp（）函数）然后会产生一个按时间顺序排列的序列。可选标点符号的存在将违反此特性。
Human readability has proved to be a valuable feature of Internet protocols. Human readable protocols greatly reduce the costs of debugging since telnet often suffices as a test client and network analyzers need not be modified with knowledge of the protocol. On the other hand, human readability sometimes results in interoperability problems. For example, the date format "10/11/1996" is completely unsuitable for global interchange because it is interpreted differently in different countries. In addition, the date format in [IMAIL] has resulted in interoperability problems when people assumed any text string was permitted and translated the three letter abbreviations to other languages or substituted date formats which were easier to generate (e.g. the format used by the C function ctime). For this reason, a balance must be struck between human readability and interoperability.
人类可读性已被证明是互联网协议的一个重要特征。人类可读的协议大大降低了调试成本，因为telnet通常足以作为测试客户机，并且不需要使用协议知识修改网络分析器。另一方面，人的可读性有时会导致互操作性问题。例如，日期格式“10/11/1996”完全不适合全球交换，因为不同国家对其的解释不同。此外，[IMAIL]中的日期格式导致了互操作性问题，因为人们假设允许使用任何文本字符串，并将三个字母的缩写翻译成其他语言或更容易生成的替代日期格式（例如，C函数ctime使用的格式）。因此，必须在人类可读性和互操作性之间取得平衡。
Because no date and time format is readable according to the conventions of all countries, Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality. This may include translating UTC to local time.
由于根据所有国家的惯例，没有任何日期和时间格式是可读的，因此互联网客户端应准备将日期转换为适合本地的显示格式。这可能包括将UTC转换为当地时间。
A format which includes rarely used options is likely to cause interoperability problems. This is because rarely used options are less likely to be used in alpha or beta testing, so bugs in parsing are less likely to be discovered. Rarely used options should be made mandatory or omitted for the sake of interoperability whenever possible.
包含很少使用的选项的格式可能会导致互操作性问题。这是因为很少使用的选项不太可能在alpha或beta测试中使用，因此解析中的错误不太可能被发现。出于互操作性的考虑，应尽可能强制或省略很少使用的选项。
The format defined below includes only one rarely used option: fractions of a second. It is expected that this will be used only by applications which require strict ordering of date/time stamps or which have an unusual precision requirement.
下面定义的格式只包括一个很少使用的选项：分数秒。预计这将仅用于需要严格排序日期/时间戳或具有异常精度要求的应用程序。
If a date/time format includes redundant information, that introduces the possibility that the redundant information will not correlate. For example, including the day of the week in a date/time format introduces the possibility that the day of week is incorrect but the date is correct, or vice versa. Since it is not difficult to compute the day of week from a date (see Appendix B), the day of week should not be included in a date/time format.
如果日期/时间格式包含冗余信息，则可能导致冗余信息不相关。例如，将一周中的某一天包含在日期/时间格式中，可能会导致一周中的某一天不正确，但日期正确，反之亦然。由于从一个日期计算星期几并不困难（见附录B），因此星期几不应包含在日期/时间格式中。
The complete set of date and time formats specified in ISO 8601 [ISO8601] is quite complex in an attempt to provide multiple representations and partial representations. Appendix A contains an attempt to translate the complete syntax of ISO 8601 into ABNF. Internet protocols have somewhat different requirements and simplicity has proved to be an important characteristic. In addition, Internet protocols usually need complete specification of data in order to achieve true interoperability. Therefore, the complete grammar for ISO 8601 is deemed too complex for most Internet protocols.
ISO 8601[ISO8601]中规定的一整套日期和时间格式非常复杂，试图提供多种表示和部分表示。附录A试图将ISO 8601的完整语法翻译成ABNF。Internet协议有一些不同的要求，简单性已被证明是一个重要特征。此外，为了实现真正的互操作性，Internet协议通常需要完整的数据规范。因此，ISO 8601的完整语法对于大多数互联网协议来说过于复杂。
The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. Simplicity is achieved by making most fields and punctuation mandatory.
下一节定义了在Internet上使用的ISO 8601配置文件。它是ISO 8601扩展格式的一致子集。简化是通过强制大多数字段和标点符号来实现的。
The following profile of ISO 8601 [ISO8601] dates SHOULD be used in new protocols on the Internet. This is specified using the syntax description notation defined in [ABNF].
互联网上的新协议应使用以下ISO 8601[ISO8601]日期配置文件。这是使用[ABNF]中定义的语法描述符号指定的。
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday full-time = partial-time time-offset
部分时间=时间小时“：“时间分钟”：“时间秒[time secfrac]完整日期=日期完整年份”—“日期-月份”—“日期-日期-日期-日期-完整时间=部分时间-时间偏移
date-time = full-date "T" full-time
日期时间=完整日期“T”完整时间
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively.
注：根据[ABNF]和ISO8601，此语法中的“T”和“Z”字符可以分别为小写“T”或“Z”。
This date/time format may be used in some environments or contexts that distinguish between the upper- and lower-case letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use this format in such environments MAY further limit the date/time syntax so that the letters 'T' and 'Z' used in the date/time syntax must always be upper case. Applications that generate this format SHOULD use upper case letters.
此日期/时间格式可用于区分大写字母“A”-“Z”和小写字母“A”-“Z”（如XML）的某些环境或上下文中。在此类环境中使用此格式的规范可能会进一步限制日期/时间语法，因此日期/时间语法中使用的字母“T”和“Z”必须始终为大写。生成此格式的应用程序应使用大写字母。
NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character.
注：ISO 8601定义了以“T”分隔的日期和时间。出于可读性考虑，使用此语法的应用程序可能会选择指定一个完整日期和完整时间，并用（比如）空格字符分隔。
The grammar element date-mday represents the day number within the current month. The maximum value varies based on the month and year as follows:
语法元素date mday表示当前月份内的天数。最大值根据月份和年份的不同而变化，如下所示：
Month Number Month/Year Maximum value of date-mday
------------ ---------- --------------------------
01 January 31
02 February, normal 28
02 February, leap year 29
03 March 31
04 April 30
05 May 31
06 June 30
07 July 31
08 August 31
09 September 30
10 October 31
11 November 30
12 December 31
Month Number Month/Year Maximum value of date-mday
------------ ---------- --------------------------
01 January 31
02 February, normal 28
02 February, leap year 29
03 March 31
04 April 30
05 May 31
06 June 30
07 July 31
08 August 31
09 September 30
10 October 31
11 November 30
12 December 31
Appendix C contains sample C code to determine if a year is a leap year.
附录C包含确定一年是否为闰年的示例C代码。
The grammar element time-second may have the value "60" at the end of months in which a leap second occurs -- to date: June (XXXX-06- 30T23:59:60Z) or December (XXXX-12-31T23:59:60Z); see Appendix D for a table of leap seconds. It is also possible for a leap second to be subtracted, at which times the maximum value of time-second is "58". At all other times the maximum value of time-second is "59". Further, in time zones other than "Z", the leap second point is shifted by the zone offset (so it happens at the same instant around the globe).
语法元素time second可能在闰秒发生的月份结束时具有值“60”——到目前为止：六月（XXXX-06-30T23:59:60Z）或十二月（XXXX-12-31T23:59:60Z）；闰秒表见附录D。也可以减去闰秒，此时时间秒的最大值为“58”。在所有其他时间，时间秒的最大值为“59”。此外，在“Z”以外的时区中，闰秒点会随着时区偏移而移动（因此它在全球范围内同时发生）。
Leap seconds cannot be predicted far into the future. The International Earth Rotation Service publishes bulletins [IERS] that announce leap seconds with a few weeks' warning. Applications should not generate timestamps involving inserted leap seconds until after the leap seconds are announced.
闰秒无法预测到遥远的未来。国际地球自转服务发布公告，宣布闰秒，并提前几周发出警告。在宣布闰秒之前，应用程序不应生成涉及插入闰秒的时间戳。
Although ISO 8601 permits the hour to be "24", this profile of ISO 8601 only allows values between "00" and "23" for the hour in order to reduce confusion.
虽然ISO 8601允许小时为“24”，但ISO 8601的此配置文件仅允许小时值在“00”和“23”之间，以减少混淆。
Here are some examples of Internet date/time format.
以下是一些Internet日期/时间格式的示例。
1985-04-12T23:20:50.52Z
1985-04-12T23:20:50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC.
这表示UTC 1985年4月12日23小时后20分50.52秒。
1996-12-19T16:39:57-08:00
1996-12-19T16:39:57-08:00
This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC (Pacific Standard Time). Note that this is equivalent to 1996-12-20T00:39:57Z in UTC.
这表示1996年12月19日16小时后39分57秒，与UTC（太平洋标准时间）的偏移量为-08:00。请注意，这相当于UTC中的1996-12-20T00:39:57Z。
1990-12-31T23:59:60Z
1990-12-31T23:59:60Z
This represents the leap second inserted at the end of 1990.
这代表了1990年底插入的闰秒。
1990-12-31T15:59:60-08:00
1990-12-31T15:59:60-08:00
This represents the same leap second in Pacific Standard Time, 8 hours behind UTC.
这表示太平洋标准时间的相同闰秒，比UTC晚8小时。
1937-01-01T12:00:27.87+00:20
1937-01-01T12:00:27.87+00:20
This represents the same instant of time as noon, January 1, 1937, Netherlands time. Standard time in the Netherlands was exactly 19 minutes and 32.13 seconds ahead of UTC by law from 1909-05-01 through 1937-06-30. This time zone cannot be represented exactly using the HH:MM format, and this timestamp uses the closest representable UTC offset.
这与荷兰时间1937年1月1日中午的时间相同。从1909-05-01年到1937-06-30年，荷兰的标准时间比UTC法定时间提前19分32.13秒。无法使用HH:MM格式准确表示此时区，此时间戳使用最接近的可表示UTC偏移量。
[ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol. 9, Nov 1886.
《数学学报》，第9卷，1886年11月。
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text Messages", STD 11, RFC 822, August 1982.
[IMAIL]Crocker，D.，“Arpa互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[IMAIL-UPDATE]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[ISO8601] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:1988(E), International Organization for Standardization, June, 1988.
[ISO8601]“数据元和交换格式——信息交换——日期和时间的表示”，ISO 8601:1988（E），国际标准化组织，1988年6月。
[ISO8601:2000] "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601:2000, International Organization for Standardization, December, 2000.
[ISO8601:2000]“数据元素和交换格式——信息交换——日期和时间的表示”，ISO 8601:2000，国际标准化组织，2000年12月。
[HOST-REQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[HOST-REQ]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[IERS] International Earth Rotation Service Bulletins, <http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
[IERS]国际地球自转服务公告<http://hpiers.obspm.fr/eop-pc/products/bulletins.html>.
[NTP] Mills, D, "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP]Mills，D，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[ITU-R-TF] International Telecommunication Union Recommendations
for Time Signals and Frequency Standards Emissions.
<http://www.itu.ch/publications/itu-r/iturtf.htm>
[ITU-R-TF] International Telecommunication Union Recommendations
for Time Signals and Frequency Standards Emissions.
<http://www.itu.ch/publications/itu-r/iturtf.htm>
[RFC2119] Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Since the local time zone of a site may be useful for determining a time when systems are less likely to be monitored and might be more susceptible to a security probe, some sites may wish to emit times in UTC only. Others might consider this to be loss of useful functionality at the hands of paranoia.
由于站点的本地时区可能有助于确定系统不太可能受到监控且可能更容易受到安全探测的时间，因此某些站点可能希望仅以UTC为单位发出时间。其他人可能认为这是在偏执狂手中失去有用的功能。
This information is based on the 1988 version of ISO 8601. There may be some changes in the 2000 revision.
此信息基于1988版ISO 8601。2000年修订版可能会有一些变化。
ISO 8601 does not specify a formal grammar for the date and time formats it defines. The following is an attempt to create a formal grammar from ISO 8601. This is informational only and may contain errors. ISO 8601 remains the authoritative reference.
ISO 8601没有为其定义的日期和时间格式指定正式语法。以下是从ISO8601创建正式语法的尝试。这仅供参考，可能包含错误。ISO 8601仍然是权威参考。
Note that due to ambiguities in ISO 8601, some interpretations had to be made. First, ISO 8601 is not clear if mixtures of basic and extended format are permissible. This grammar permits mixtures. ISO 8601 is not clear on whether an hour of 24 is permissible only if minutes and seconds are 0. This assumes that an hour of 24 is permissible in any context. Restrictions on date-mday in section 5.7 apply. ISO 8601 states that the "T" may be omitted under some circumstances. This grammar requires the "T" to avoid ambiguity. ISO 8601 also requires (in section 5.3.1.3) that a decimal fraction be proceeded by a "0" if less than unity. Annex B.2 of ISO 8601 gives examples where the decimal fractions are not preceded by a "0". This grammar assumes section 5.3.1.3 is correct and that Annex B.2 is in error.
请注意，由于ISO 8601中的歧义，必须做出一些解释。首先，ISO 8601不清楚是否允许混合使用基本格式和扩展格式。这种语法允许混合。ISO 8601不清楚24小时是否仅在分和秒为0时才允许。这假设在任何情况下都允许24小时。第5.7节中的日期限制适用。ISO 8601规定在某些情况下可以省略“T”。这种语法需要“T”来避免歧义。ISO 8601还要求（在第5.3.1.3节中），如果小于1，则小数部分应以“0”进行。ISO 8601附录B.2给出了小数点前未加“0”的示例。本语法假设第5.3.1.3节是正确的，附录B.2是错误的。
date-century = 2DIGIT ; 00-99
date-decade = DIGIT ; 0-9
date-subdecade = DIGIT ; 0-9
date-year = date-decade date-subdecade
date-fullyear = date-century date-year
date-month = 2DIGIT ; 01-12
date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
date-yday = 3DIGIT ; 001-365, 001-366 based on year
date-week = 2DIGIT ; 01-52, 01-53 based on year
date-century = 2DIGIT ; 00-99
date-decade = DIGIT ; 0-9
date-subdecade = DIGIT ; 0-9
date-year = date-decade date-subdecade
date-fullyear = date-century date-year
date-month = 2DIGIT ; 01-12
date-wday = DIGIT ; 1-7 ; 1 is Monday, 7 is Sunday
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
date-yday = 3DIGIT ; 001-365, 001-366 based on year
date-week = 2DIGIT ; 01-52, 01-53 based on year
datepart-fullyear = [date-century] date-year ["-"]
datepart-ptyear = "-" [date-subdecade ["-"]]
datepart-wkyear = datepart-ptyear / datepart-fullyear
datepart-fullyear = [date-century] date-year ["-"]
datepart-ptyear = "-" [date-subdecade ["-"]]
datepart-wkyear = datepart-ptyear / datepart-fullyear
dateopt-century = "-" / date-century
dateopt-fullyear = "-" / datepart-fullyear
dateopt-year = "-" / (date-year ["-"])
dateopt-month = "-" / (date-month ["-"])
dateopt-week = "-" / (date-week ["-"])
dateopt-century = "-" / date-century
dateopt-fullyear = "-" / datepart-fullyear
dateopt-year = "-" / (date-year ["-"])
dateopt-month = "-" / (date-month ["-"])
dateopt-week = "-" / (date-week ["-"])
datespec-full = datepart-fullyear date-month ["-"] date-mday
datespec-year = date-century / dateopt-century date-year
datespec-month = "-" dateopt-year date-month [["-"] date-mday]
datespec-mday = "--" dateopt-month date-mday
datespec-week = datepart-wkyear "W"
(date-week / dateopt-week date-wday)
datespec-wday = "---" date-wday
datespec-yday = dateopt-fullyear date-yday
datespec-full = datepart-fullyear date-month ["-"] date-mday
datespec-year = date-century / dateopt-century date-year
datespec-month = "-" dateopt-year date-month [["-"] date-mday]
datespec-mday = "--" dateopt-month date-mday
datespec-week = datepart-wkyear "W"
(date-week / dateopt-week date-wday)
datespec-wday = "---" date-wday
datespec-yday = dateopt-fullyear date-yday
date = datespec-full / datespec-year
/ datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-yday
date = datespec-full / datespec-year
/ datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-yday
Time:
时间：
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
time-hour = 2DIGIT ; 00-24
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on
; leap-second rules
time-fraction = ("," / ".") 1*DIGIT
time-numoffset = ("+" / "-") time-hour [[":"] time-minute]
time-zone = "Z" / time-numoffset
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timeopt-hour = "-" / (time-hour [":"])
timeopt-minute = "-" / (time-minute [":"])
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
timespec-hour = time-hour [[":"] time-minute [[":"] time-second]]
timespec-minute = timeopt-hour time-minute [[":"] time-second]
timespec-second = "-" timeopt-minute time-second
timespec-base = timespec-hour / timespec-minute / timespec-second
time = timespec-base [time-fraction] [time-zone]
时间=timespec基准[时间分数][时区]
iso-date-time = date "T" time
iso日期时间=日期“T”时间
Durations:
持续时间：
dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
duration = "P" (dur-date / dur-time / dur-week)
duration = "P" (dur-date / dur-time / dur-week)
Periods:
时期：
period-explicit = iso-date-time "/" iso-date-time
period-start = iso-date-time "/" duration
period-end = duration "/" iso-date-time
period-explicit = iso-date-time "/" iso-date-time
period-start = iso-date-time "/" duration
period-end = duration "/" iso-date-time
period = period-explicit / period-start / period-end
period = period-explicit / period-start / period-end
The following is a sample C subroutine loosely based on Zeller's Congruence [Zeller] which may be used to obtain the day of the week for dates on or after 0000-03-01:
以下是一个基于Zeller同余[Zeller]的示例C子程序，可用于获取0000-03-01或0000-03-01之后日期的星期几：
char *day_of_week(int day, int month, int year)
{
int cent;
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
};
char *day_of_week(int day, int month, int year)
{
int cent;
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
};
/* adjust months so February is the last one */
month -= 2;
if (month < 1) {
month += 12;
--year;
}
/* split by century */
cent = year / 100;
year %= 100;
return (dayofweek[((26 * month - 2) / 10 + day + year
+ year / 4 + cent / 4 + 5 * cent) % 7]);
}
/* adjust months so February is the last one */
month -= 2;
if (month < 1) {
month += 12;
--year;
}
/* split by century */
cent = year / 100;
year %= 100;
return (dayofweek[((26 * month - 2) / 10 + day + year
+ year / 4 + cent / 4 + 5 * cent) % 7]);
}
Here is a sample C subroutine to calculate if a year is a leap year:
下面是一个示例C子程序，用于计算一年是否为闰年：
/* This returns non-zero if year is a leap year. Must use 4 digit
year.
*/
int leap_year(int year)
{
return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
}
/* This returns non-zero if year is a leap year. Must use 4 digit
year.
*/
int leap_year(int year)
{
return (year % 4 == 0 && (year % 100 != 0 || year % 400 == 0));
}
Information about leap seconds can be found at: <http://tycho.usno.navy.mil/leapsec.html>. In particular, it notes that:
有关闰秒的信息，请访问：<http://tycho.usno.navy.mil/leapsec.html>. 委员会特别注意到：
The decision to introduce a leap second in UTC is the responsibility of the International Earth Rotation Service (IERS). According to the CCIR Recommendation, first preference is given to the opportunities at the end of December and June, and second preference to those at the end of March and September.
在UTC中引入闰秒的决定由国际地球自转服务（IERS）负责。根据CCIR建议，第一优先考虑12月底和6月底的机会，第二优先考虑3月底和9月底的机会。
When required, insertion of a leap second occurs as an extra second at the end of a day in UTC, represented by a timestamp of the form YYYY-MM-DDT23:59:60Z. A leap second occurs simultaneously in all time zones, so that time zone relationships are not affected. See section 5.8 for some examples of leap second times.
必要时，在UTC中，在一天结束时插入闰秒作为额外的一秒，由格式为YYYY-MM-DDT23:59:60Z的时间戳表示。闰秒在所有时区中同时发生，因此时区关系不受影响。有关闰秒时间的一些示例，请参见第5.8节。
The following table is an excerpt from the table maintained by the United States Naval Observatory. The source data is located at:
下表摘自美国海军天文台维护的表格。源数据位于：
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
This table shows the date of the leap second, and the difference between the time standard TAI (which isn't adjusted by leap seconds) and UTC after that leap second.
此表显示了闰秒的日期，以及闰秒后时间标准TAI（不按闰秒调整）和UTC之间的差异。
UTC Date TAI - UTC After Leap Second
-------- ---------------------------
1972-06-30 11
1972-12-31 12
1973-12-31 13
1974-12-31 14
1975-12-31 15
1976-12-31 16
1977-12-31 17
1978-12-31 18
1979-12-31 19
1981-06-30 20
1982-06-30 21
1983-06-30 22
1985-06-30 23
1987-12-31 24
1989-12-31 25
1990-12-31 26
1992-06-30 27
1993-06-30 28
1994-06-30 29
1995-12-31 30
1997-06-30 31
1998-12-31 32
UTC Date TAI - UTC After Leap Second
-------- ---------------------------
1972-06-30 11
1972-12-31 12
1973-12-31 13
1974-12-31 14
1975-12-31 15
1976-12-31 16
1977-12-31 17
1978-12-31 18
1979-12-31 19
1981-06-30 20
1982-06-30 21
1983-06-30 22
1985-06-30 23
1987-12-31 24
1989-12-31 25
1990-12-31 26
1992-06-30 27
1993-06-30 28
1994-06-30 29
1995-12-31 30
1997-06-30 31
1998-12-31 32
Acknowledgements
致谢
The following people provided helpful advice for an earlier incarnation of this document: Ned Freed, Neal McBurnett, David Keegel, Markus Kuhn, Paul Eggert and Robert Elz. Thanks are also due to participants of the IETF Calendaring/Scheduling working group mailing list, and participants of the time zone mailing list.
以下人士为本文件的早期版本提供了有用的建议：内德·弗里德、尼尔·麦克伯内特、大卫·基格尔、马库斯·库恩、保罗·艾格特和罗伯特·埃尔兹。还要感谢IETF日历/日程安排工作组邮件列表的参与者和时区邮件列表的参与者。
The following reviewers contributed helpful suggestions for the present revision: Tom Harsch, Markus Kuhn, Pete Resnick, Dan Kohn. Paul Eggert provided many careful observations regarding the subtleties of leap seconds and time zone offsets. The following people noted corrections and improvements to earlier drafts: Dr John Stockton, Jutta Degener, Joe Abley, and Dan Wing.
以下审稿人为本次修订提供了有益的建议：汤姆·哈什、马库斯·库恩、皮特·雷斯尼克、丹·科恩。保罗·艾格特（Paul Eggert）就闰秒和时区偏移的微妙之处提供了许多仔细的观察。以下人员注意到了对早期草稿的更正和改进：约翰·斯托克顿博士、朱塔·德詹、乔·阿贝利和丹·温。
Authors' Addresses
作者地址
Chris Newman Sun Microsystems 1050 Lakes Drive, Suite 250 West Covina, CA 91790 USA
Chris Newman Sun Microsystems 1050 Lakes Drive，美国加利福尼亚州西科维纳250号套房，邮编：91790
EMail: chris.newman@sun.com
EMail: chris.newman@sun.com
Graham Klyne (editor, this revision) Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
格雷厄姆·克莱恩（编辑，本次修订）Clearwift Corporation 1310水边阿灵顿商业公园Theale，阅读英国RG7 4SA
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。