インターネット上での日付と時刻：タイムスタンプ（日付と時刻の書式）

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

   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.

   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.

   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.

   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.

   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.

   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.

   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.

   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.