5. 日付と時刻の書式

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

この章は、日付と時間の書式における望ましい特質について論じ、インターネットプロトコルで用いるISO 8601プロフィールを定義するものである。

5.1. 順序

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


5.3. 稀なオプション

   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


   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. 冗長な情報

   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. 曜日」を参照)、日付と時刻の書式に曜日を含めるべきではない。

5.5. 単純さ

   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

ISO 8601で定義された日付と時間の書式の完全な集合は、多数の表現及び部分的な表現を範囲に含むため非常に複雑である。「付記A. ISO 8601のABNF集」にISO 8601の完全な構文をABNFに変換する試みがある。インターネットプロトコルは多少異なる必要条件を持っており、単純であることが重要な特性であることも実証されている。さらに、インターネットプロトコルは、通常完全な相互互換が求められるためデータの完全な仕様が要求されることとなる。そのため、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

次の章は、インターネットで用いられるISO 8601のプロフィールを定義するものである。これは、ISO 8601の拡張書式に従う部分集合であり、殆どのフィールドと句読点を必須とすることにより単純なものとなっている。

5.6. インターネットにおける日付と時刻の書式

   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日付のプロフィールを、新しく勧告するインターネットプロトコルで用いるべきである(SHOULD)。これは、[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
   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.

注記:[ABNF]とISO 8601において、この構文の文字"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.


      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"によって区切られた日付と時刻を定義する。この構文を用いるアプリケーションは読み易さのために、空白で区切った完全な日付と完全な時刻の指定を選択することがある。

5.7. 制限

   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


付記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"を取ることがある(6月:XXXX-06-30T23:59:60Z、又は12月:XXXX-12-31T23:59:60Z)。うるう秒の一覧については「付記D. うるう秒」を参照のこと。うるう秒は少なくなる可能性もあり、その際time-secondの取り得る最大値は"58"となる。他の場合、time-secondの取り得る最大値は"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"の時間の値だけを認めるものとする。

5.8. 例

   Here are some examples of Internet date/time format.



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



   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.



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



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



   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



Copyright (C) 2006 七鍵 key@do.ai 初版:2006年10月06日 最終更新:2006年10月09日