rfc3339.txt

RFC 的详细文档！

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

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.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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.

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



Klyne, et. al.              Standards Track                     [Page 1]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002


   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

1. Introduction

   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.

   This document includes an Internet profile of the ISO 8601 [ISO8601]
   standard for representation of dates and times using the Gregorian
   calendar.

   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:

   o  All dates and times are assumed to be in the "current era",
      somewhere between 0000AD and 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  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  Date and time expressions indicate an instant in time.
      Description of time periods, or intervals, is not covered here.







Klyne, et. al.              Standards Track                     [Page 2]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002


2. Definitions

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

      UTC         Coordinated Universal Time as maintained by the Bureau
                  International des Poids et Mesures (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.

      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.

      hour        A period of time of 60 minutes.

      day         A period of time of 24 hours.

      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.

      ABNF        Augmented Backus-Naur Form, a format used to represent
                  permissible strings in a protocol or language, as
                  defined in [ABNF].

      Email Date/Time Format
                  The date/time format used by Internet Mail as defined
                  by RFC 2822 [IMAIL-UPDATE].

      Internet Date/Time Format
                  The date format defined in section 5 of this document.

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



Klyne, et. al.              Standards Track                     [Page 3]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002


      For more information about time scales, see Appendix E of [NTP],
      Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-
      TF].

3. Two Digit Years

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

   The problems with two digit years amply demonstrate why all dates and
   times used in Internet protocols MUST be fully qualified.

4. Local Time

4.1. Coordinated Universal Time (UTC)

   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.








Klyne, et. al.              Standards Track                     [Page 4]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002


4.2. Local Offsets

   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.

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

      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.

4.3. Unknown Local Offset Convention

   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.

4.4. Unqualified Local Time

   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:

   o  Use Network Time Protocol [NTP] to obtain the time in UTC.




Klyne, et. al.              Standards Track                     [Page 5]

RFC 3339       Date and Time on the Internet: Timestamps       July 2002


   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  Prompt the user for the local time zone and daylight saving rule
      settings.

5. Date and Time format

   This section discusses desirable qualities of date and time formats
   and defines a profile of ISO 8601 for use in Internet protocols.

5.1. Ordering

   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.

5.2. Human Readability

   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.

   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.







Klyne, et. al.              Standards Track                     [Page 6]