この文書はRFC3339の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はグレゴリオカレンダーを使う日付と時間の表現の、ISO 8601
標準のプロフィールで、インターネット・プロトコルでの使用する日付
と時間のフォーマットを定義します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Definitions
2. 定義
3. Two Digit Years
3. ２桁の年
4. Local Time
4. ローカル時間
4.1. Coordinated Universal Time (UTC)
4.1. 協定標準時(UTC)
4.2. Local Offsets
4.2. 現地時間オフセット
4.3. Unknown Local Offset Convention
4.3. 未知の現地時間オフセットの慣習
4.4. Unqualified Local Time
4.4. 無資格の現地時間
5. Date and Time format
5. 日付と時間のフォーマット
5.1. Ordering
5.1. 順序
5.2. Human Readability
5.2. 人間による可読性
5.3. Rarely Used Options
5.3. 稀なオプションの使用
5.4. Redundant Information
5.4. 冗長な情報
5.5. Simplicity
5.5. 単純さ
5.6. Internet Date/Time Format
5.6. インターネット日付／時間フォーマット
5.7. Restrictions
5.7. 制限
5.8. Examples
5.8. 例
6. References
6. 参考文献
7. Security Considerations
7. セキュリティの考慮
Appendix A. ISO 8601 Collected ABNF
付録Ａ ISO 8601のABNF集
Appendix B. Day of the Week
付録Ｂ：曜日
Appendix C. Leap Years
付録Ｂ：うるう年
Appendix D. Leap Seconds
付録Ｂ：うるう秒
Acknowledgements
謝辞
Authors' Addresses
著者のアドレス
Full Copyright Statement
著作権表示全文
1. Introduction
1. はじめに
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.
この文書はグレゴリオカレンダーを使う日付と時間の表現のISO 8601標準の
インターネットプロフィールを含みます。
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:
インターネット・プロトコルに現われる日付と時間が多くの方法があります：
この文書はインターネット・プロトコルイベントの１つの共通の使用法、
viz. タイムスタンプに焦点を合わせます。この限定された考慮は次の結果を
持っています：
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への実際の関係は
政治や管理者の未知か既知の行動に依存しているかもしれません。ニュー
ヨークで２００５年３月２３日に１７：００に対応しているUTC時はサマー
タイムについて管理上の決定に依存するかもしれません。この指定はこの
ような考察をうまく取り払います。）
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 日付と時間の表現がその時の瞬間を示します。ここでは期間や間隔の記
述を含みません。
2. Definitions
2. 定義
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].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"はRFC
2119 [RFC2119]で記述されるように解釈されます。
UTC Coordinated Universal Time as maintained by the Bureau
International des Poids et Mesures (BIPM).
UTC 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.
うるう年 グレゴリオカレンダーで、1年が３６６日の年。うるう年は
４で割り切れる年で、例外が百周年（百で割り切れる年で）、
その例外が４百で割り切れる年です。
ABNF Augmented Backus-Naur Form, a format used to represent
permissible strings in a protocol or language, as
defined in [ABNF].
ABNF [ABNF]で定義される、プロトコルあるいは言語で許される文
字列を表すための使われたフォーマット、Backus-Naurフォー
ムの拡張。
Email Date/Time Format
The date/time format used by Internet Mail as defined
by RFC 2822 [IMAIL-UPDATE].
電子メール日付／時間フォーマット。
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".
Ｚ 時刻に適用される時UTCオフセット００：００を意味する接
尾辞；ICAO音標文字表現の文字"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］の付録Ｅや、
[ISO8601]の３章や、適切なITU文書[ITU-R-TF]を見てください。
3. Two Digit Years
3. ２桁の年
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 インターネット・プロトコルが日付で４桁年を生成しなくてはなりま
せん(MUST)。
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 ２桁の年の使用は廃止されます。もし２桁の年が受信されるなら、
それは正しくない解釈がプロトコルあるいは処理の障害を起こさない
場合に限り受け入れられるべきです（例えば、もしログか、追跡の目
的にだけ使われる場合）。
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 ２桁の年を使っているプログラムが１９９９の後に何年も３桁で表示
することがあります。これは、もしプログラムが年から１９００を引
いて桁数をチェックしないなら起こります。このような壊れたソフト
ウェアによって生成された日付を強固に扱うことを望むプログラムが
３桁年に１９００を加えるかもしれません。
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 ２桁年を使っているプログラムが１９９９の後に何年も ":0", ":1",
...":9", ";0",...として描くことはありえます。これは、もしプロ
グラムがただ年から１９００を引いて、１０の桁にUS-ASCII文字ゼロ
を加えるなら起こります。このような壊れたソフトウェアによって生
成された日付を強靭に扱うことを望むプログラムが数でない数十年を
認めて、適切に翻訳するべきです。
The problems with two digit years amply demonstrate why all dates and
times used in Internet protocols MUST be fully qualified.
２桁年における問題は、なぜインターネット・プロトコルで使う日付と時間
がすべてが完全な量でなくてはならない(MUST)、かを明示します。
4. Local Time
4. ローカル時間
4.1. Coordinated Universal Time (UTC)
4.1. 協定標準時(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.
ローカル時間帯のサマータイム規則がかなり複雑で、予想できない時にロー
カル規則に基づいて変化するから、真の互換性が協定標準時（UTC）を使うこ
とによって最も良く成し遂げられます。この指定はローカルな時間帯規則を
満足させません。
4.2. Local Offsets
4.2. 現地時間オフセット
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.)
数のオフセットが「現地時間引くＵＴＣ」と計算されます。それでＵＴＣ
での等しい時間は現地時間からオフセットを引くことによって決定できま
す。例えば、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と異なります。正確にこのような歴史的タイムスタンプ
を表すために、アプリケーションがそれらを表示することができる時
間帯に変換しなくてはなりません。
4.3. Unknown Local Offset Convention
4.3. 未知の現地時間オフセットの慣習
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"の
オフセットと異なり、ＵＴＣが優先的な参照ポイントであることを示します。
RFC2822 [IMAIL-UPDATE]が電子メールのために類似の慣習を記述します。
4.4. Unqualified Local Time
4.4. 無資格の現地時間
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:
多くの現在インターネットに接続した装置が現地時間でそれらの内部の時
計を走らせて、UTCに気が付きません。インターネットが仕様書を作る時
に現実を受け入れる伝統を持っているが、互換性の問題がある場合はそう
するべきではありません。無資格のローカルな時間帯の解釈が地球のおよ
そ２３/２４で失敗するであろうので、無資格の現地時間の互換性問題は
インターネットで受け入れ難いとみなされます。現地時間で構成を設定さ
れるシステムは対応するＵＴＣオフセットに気が付かなくて、そして他の
インターネットシステムと同期が必要ならばUTCと正しい同期を保証する
メカニズムを使わなくてはなりません(MUST)。適当なメカニズムが以下で
す：
o Use Network Time Protocol [NTP] to obtain the time in UTC.
o UTC時を得るためにネットワーク時間プロトコル［NTP］を使います。
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 同じローカルな時間帯の他のホストをインターネットのゲートウェイとし
て用いてください。このホストは他のホストから伝達される無資格ローカ
ル時間を修正しなくてはなりません(MUST)。
o Prompt the user for the local time zone and daylight saving rule
settings.
o ローカル時間帯とサマータイム制規則設定の入力をユーザーに促します。
5. Date and Time format
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. Ordering
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.
もし日付と時の構成要素が「大雑把な時間」から「詳細な時間」の順で並べ
られるなら、有用な特性が達成されます。日付と時間の時間帯が同じで（例
えば、全てUTC）、同じ文字列で表現する（例えば、全て"Z"か"+00:00"）と
仮定し、そしてすべての時間は同じ桁数であれば、日付と時間の文字列は、
文字列としてソート（例えばC言語のstrcmp()を使う）でき、時間順の結果が
得られます。任意の句読点の存在はこの特徴を侵害するでしょう。
5.2. Human Readability
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.
人間による可読性がインターネット・プロトコルの貴重な特徴であることが
分かりました。人間が読むことができるプロトコルが、telnetがテストクラ
イアントとして十分で、ネットワークアナライザがプロトコルの知識で修正
される必要がないから、大いにデバッグのコストを減らします。他方、人間
の可読性が時々互換性の問題をもたらします。例えば、日付フォーマット
"10/11/1996"は、異なった国で違って解釈されるから、グローバルな交換に
完全に不適当です。加えて、［IMAIL］の日付フォーマットは、人々がどん
なテキスト文字列でも認められてると想定して、３つの文字の省略を他の言
葉に翻訳するか、あるいは生成することがより容易な日付フォーマット（例
えばＣ言語の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.
日付と時間のフォーマットがすべての国の慣習に従って読みやすいのではな
いから、インターネットクライアントは現地に適した表示フォーマットに日
付を変える用意ができるべきです(SHOULD)。これはＵＴＣを現地時間に翻訳
することを含むかもしれません。
5.3. Rarely Used Options
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
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
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.
もし日付／時間フォーマットが冗長な情報を含むなら、冗長な情報が一致し
ない可能性をもたらします。例えば、日付／時間フォーマットに曜日を含め
ると、曜日が正しくない可能性をもたらします、日付が正しいか、そうでな
いかです。日付から曜日を計算するのは難しくないので（付録Ｂ参照）、曜
日は日付／時間フォーマットに含むべきではありません。
5.5. Simplicity
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
protocols.
ISO 8601 [ISO8601]で指定された日付と時間フォーマットの完全なセットは、
多数の表現と部分的な表現を供給する試みで、非常に複雑です。付録Ａが
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
mandatory.
次の章はインターネットで使用するためにISO 8601のプロフィールを定義し
ます。それはISO 8601の延長フォーマットに従うサブセットです。たいてい
のフィールドと句読点を必須にすることで単純化します。
5.6. Internet Date/Time Format
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 [ISO8601]日付のプロフィールはインターネット上の新しい
プロトコルで使われるべきです(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
[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.
メモ：[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'が
常に大文字であるように、日付／時間構文を制限するかもしれません
(MAY)。このフォーマットを生成するアプリケーションが大文字を使うべ
きです(SHOULD)。
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"によって切り離された日付と時間を定義します。こ
の構文を使うアプリケーションは、可読性のために、full-dateと
full-timeをスペースで区切ると指定するかもしれません。
5.7. Restrictions
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:
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
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).
文法要素time-secondがうるう秒の発生する月の月末に値"60"を持つかもしれ
ません、うるう描画発生するのは：６月(XXXX-06- 30T23:59:60Z)か１２月
(XXXX-12-31T23:59:60Z)です；うるう秒の表は付録Ｄを見てください。うる
う秒は少なくなることもあり、その時は秒の最大値は"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.
将来のうるう秒が予想できません。国際地球自転サービスは数週間の警告で
うるう秒を発表する告示[IERS]を出します。アプリケーションが、うるう秒
が発表された後までうるう秒を考慮したタイムスタンプを生成するべきでは
ありません。
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. Examples
5.8. 例
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.
これはＵＴＣからのオフセット-08:00（太平洋標準時間）で、１９９６年１２
月１９日の１６時３９分５７秒を表します。これがＵＴＣの1996-12-20T00:39:57Z
と等しいことに注意してください。
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.
これはオランダ時間の１９３７年１月１日の正午ちょうどをあらわします。
オランダでの標準時間が１９０９-０５-０１から１９３７-０６-３０の間、
法律によってＵＴＣより正確に１９分と３２.１３秒進んでいました。この
時間帯はHH:MMフォーマットを使って正確に表すことができず、このタイム
スタンプはは最も近い表示可能なＵＴＣオフセットを使います。
6. References
6. 参考文献
[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.
[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
7. セキュリティの考慮
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.
システムがきちんと管理されていないときにローカルな時間帯は扱いやすい
く、セキュリティ調査に影響を与えるかもしれず、一部のサイトはＵＴＣの
みの時刻を生成することを望むかもしれません。他の人たちがこれが偏執的
で有用な機能の損失と考えるかもしれません。
Appendix A. ISO 8601 Collected ABNF
付録Ａ ISO 8601のABNF集
This information is based on the 1988 version of ISO 8601. There may
be some changes in the 2000 revision.
この情報はISO 8601の１９８８年のバージョンに基づいています。２０００
年バージョンに若干の変更があるかもしれません。
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は定義する日付と時間のフォーマットの正式な文法を指定しません。
次のことはISO 8601の正式の文法を作る試みです。これは情報的でエラーを
含んでいるかもしれません。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は２４時が、０分
０秒でだけ許されるのかどうか明確ではありません。これは２４時がどんな文
脈ででも許されると想定します。５.７章でのdate-mdayの制限が適用されます。
ISO 8601が"T"がある状況下で除かれるかもしれないと述べます。この文法は
あいまい性を避けるため"T"を必要とします。ISO 8601が１以下の少数は０に
続く事を要求します（５.３.１.３章参照）。ISO 8601の付録B.２が１０進少
数の前に０がない例を与えます。この文法は５.３.１.３章が正しく、付録
Ｂ.２が誤っていると想定します。
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 ["-"])
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
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
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
time = timespec-base [time-fraction] [time-zone]
iso-date-time = date "T" time
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]
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 = period-explicit / period-start / period-end
Appendix B. Day of the Week
付録Ｂ：曜日
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]基づいたＣ言語のサンプルサブルーチ
ンで、００００-０３-０１以降の日付の曜日を得るために使う事ができます：
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]);
}
Appendix C. Leap Years
付録Ｂ：うるう年
Here is a sample C subroutine to calculate if a year is a leap year:
これは、ある年がうるう年かどうか計算するＣ言語のサンプルサブルーチンです：
/* 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));
}
Appendix D. Leap Seconds
付録Ｂ：うるう秒
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.
ＵＴＣでうるう秒を導入する決定は国際地球自転サービス（IERS）の責任
です。CCIR勧告によれば、最初の１２月と６月の終わりが導入する際の優
先箇所で、３月と９月の終わりが２番目の優先順位の導入箇所です。
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.
必要な時、うるう秒の挿入は、ＵＴＣの１日の終わりに余分な秒を生じ、
書式はYYYY-MM-DDT23:59:60Zと表現されます。うるう秒がすべての時間帯
で同時に起こり、そのため時間帯関係に影響しません。
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>
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.
この表はうるう秒の日付と、（うるう秒の調整をされない）ＴＡＩ標準時と、
うるう秒の調整後のＵＴＣの間の相違を示します。
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.
次の人々はこの文書の以前版の助けになるアドバイスを提供しました：
Ned Freed、Neal McBurnett、David Keegel、Markus Kuhn、Paul Eggert、
Robert Elz.。同じく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.
次の評者は現在の修正の助けになる提案を提供しました：Tom Harsch、Markus
Kuhn、Pete Resnick、Dan Kohn。Paul Eggertはうるう秒と時間帯オフセットの
微妙な点に関しての多くの注意深い観察を供給しました。次の人々は訂正と以
前のドラフトへの改良を指摘しました：Dr John Stockton、Jutta Degener、
Joe Abley、Dan Wing。
Authors' Addresses
著者のアドレス
Chris Newman
Sun Microsystems
1050 Lakes Drive, Suite 250
West Covina, CA 91790 USA
EMail: chris.newman@sun.com
Graham Klyne (editor, this revision)
Clearswift Corporation
1310 Waterside
Arlington Business Park
Theale, Reading RG7 4SA
UK
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.
著作権（Ｃ）インターネット学会（２００１）。すべての権利は保留される。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。