rfc3339.txt

RFC 的详细文档！


RFC 3339       Date and Time on the Internet: Timestamps       July 2002


5.3. Rarely Used Options

   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.

   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.

5.4. Redundant Information

   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.

5.5. Simplicity

   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.

   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.










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


5.6. Internet Date/Time Format

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

   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

   date-time       = full-date "T" full-time

      NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
      syntax may alternatively be lower case "t" or "z" respectively.

      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.

      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.











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


5.7. Restrictions

   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:

      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.

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

   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.







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


5.8. Examples

   Here are some examples of Internet date/time format.

      1985-04-12T23:20:50.52Z

   This represents 20 minutes and 50.52 seconds after the 23rd hour of
   April 12th, 1985 in UTC.

      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.

      1990-12-31T23:59:60Z

   This represents the leap second inserted at the end of 1990.

      1990-12-31T15:59:60-08:00

   This represents the same leap second in Pacific Standard Time, 8
   hours behind UTC.

      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.

6. References

   [ZELLER]       Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol.
                  9, Nov 1886.

   [IMAIL]        Crocker, D., "Standard for the Format of Arpa Internet
                  Text Messages", STD 11, RFC 822, August 1982.

   [IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822,
                  April 2001.

   [ABNF]         Crocker, D. and P. Overell, "Augmented BNF for Syntax
                  Specifications: ABNF", RFC 2234, November 1997.




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


   [ISO8601]      "Data elements and interchange formats -- Information
                  interchange -- Representation of dates and times", ISO
                  8601:1988(E), International Organization for
                  Standardization, June, 1988.

   [ISO8601:2000] "Data elements and interchange formats -- Information
                  interchange -- Representation of dates and times", ISO
                  8601:2000, International Organization for
                  Standardization, December, 2000.

   [HOST-REQ]     Braden, R., "Requirements for Internet Hosts --
                  Application and Support", STD 3, RFC 1123, October
                  1989.

   [IERS]         International Earth Rotation Service Bulletins,
                  <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.

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

7. Security Considerations

   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.















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


Appendix A. ISO 8601 Collected ABNF

   This information is based on the 1988 version of ISO 8601.  There may
   be some changes in the 2000 revision.

   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.

   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.

   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

   dateopt-century   = "-" / date-century
   dateopt-fullyear  = "-" / datepart-fullyear
   dateopt-year      = "-" / (date-year ["-"])
   dateopt-month     = "-" / (date-month ["-"])
   dateopt-week      = "-" / (date-week ["-"])






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