RFC3339 日本語訳
3339 Date and Time on the Internet: Timestamps. G. Klyne, C. Newman. July 2002. (Format: TXT=35064 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Klyne
Request for Comments: 3339 Clearswift Corporation
Category: Standards Track C. Newman
Sun Microsystems
July 2002
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 3339年のClearswift社のカテゴリ: 標準化過程C.ニューマンサン・マイクロシステムズ2002年7月
Date and Time on the Internet: Timestamps
インターネットの日時: タイムスタンプ
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(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.
このドキュメントは、インターネットプロトコルにおける8601年の日付と回の表現のISO規格のプロフィールである使用のためにグレゴリオ暦を使用することで日時の書式を定義します。
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
1. 序論… 2 2. 定義… 3 3. 2ケタ年… 4 4. 現地時間… 4 4.1. 協定世界時(UTC)… 4 4.2. 地方のオフセット… 5 4.3. 未知の地方のオフセットコンベンション… 5 4.4. 資格のない現地時間…………………………。 5 5. 日付とTime形式… 6 5.1. 注文します… 6 5.2. 人間の読み易さ… 6 5.3. めったにオプションを使用しません… 7 5.4. 余分な情報… 7 5.5. 簡単さ… 7 5.6. インターネット日付/時間形式… 8 5.7. 制限… 9 5.8. 例… 10 6. 参照… 10 7. セキュリティ問題… 11
Klyne, et. al. Standards Track [Page 1] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[1ページ]: タイムスタンプ2002年7月
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
付録A.ISO8601はABNFを集めました… 12 付録B.曜日… 14 付録C.うるう年… 14 付録D.飛躍秒…,... 15の承認… 17人の作者のアドレス… 17 完全な著作権宣言文… 18
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.
このドキュメントは、グレゴリオ暦を使用することで日付と回の表現のISO8601[ISO8601]規格のインターネットプロフィールを含んでいます。
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:
日時の値がインターネットプロトコルに現れるかもしれない多くの方法があります: このドキュメントはつまり、ちょうど1つの一般的な用法、インターネットプロトコルイベントのためのタイムスタンプに焦点を合わせます。 この限られた考慮には、以下の結果があります:
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)まで述べられた関係を持っています(相殺します)。 (これは何らかの用法と現地時間の1時と位置が知られているかもしれませんが、UTCとの実際の関係が政治家か管理者の未知の、または、不可知の動きに依存しているかもしれないアプリケーションの計画をするのにおいて異なっています。 ニューヨークで2005年3月23日17:00に対応する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 日時の表現は時間内に、瞬間を示します。 期間、または間隔の記述はここにカバーされていません。
Klyne, et. al. Standards Track [Page 2] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[2ページ]: タイムスタンプ2002年7月
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
UTC Coordinated Universal Time as maintained by the Bureau
International des Poids et Mesures (BIPM).
国際度量衡局(BIPM)によって維持されるUTC協定世界時。
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.
SI単位系における、時間の測定の2A番目の原単位。 それはそれらの外部の分野のそばで乱されていない基底状態における、セシウム-133の原子の「超-罰金」変遷で吸収するか、または放つ91億9263万1770サイクルの電子レンジ光の持続時間と定義されます。
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.
60秒の微小なA期間。 しかしながら、また、飛躍秒が数分以内にどう指示されるかためにセクション5.7とAppendix Dの制限を見てください。
hour A period of time of 60 minutes.
60分のA期間時間。
day A period of time of 24 hours.
24時間の日のA期間。
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.
うるう年Inグレゴリオ暦、366日間がある1年。 それがまた、1整数あたり400で回で分割可能であるという百周年の年(すなわち、100で分割可能な)であるなら、うるう年は番号がそれを除いた不可欠の数の回4で分割可能である1年です。
ABNF Augmented Backus-Naur Form, a format used to represent
permissible strings in a protocol or language, as
defined in [ABNF].
ABNF Augmented BN記法、形式は以前は[ABNF]で定義されるようにプロトコルか言語で許されているストリングをよく表していました。
Email Date/Time Format
The date/time format used by Internet Mail as defined
by RFC 2822 [IMAIL-UPDATE].
RFC2822[IMAIL-UPDATE]によって定義されるようにインターネットメールによって使用される日付/時間形式をDate/時間Formatにメールしてください。
Internet Date/Time Format
The date format defined in section 5 of this document.
日付の形式がセクションでこの5通のドキュメントを定義したインターネットDate/時間Format。
Timestamp This term is used in this document to refer to an
unambiguous representation of some instant in time.
タイムスタンプThis用語は、時間内に即時のいくつかの明白な表現を示すのに本書では使用されます。
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".
時間に適用されると00:00のUTCオフセットを指示するZ A接尾語。 文字「Z」のICAO音標文字表現からのしばしば話された「ズールー族。」
Klyne, et. al. Standards Track [Page 3] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[3ページ]: タイムスタンプ2002年7月
For more information about time scales, see Appendix E of [NTP],
Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-
TF].
より多くの情報そろそろ時間のスケールに関しては、[NTP]のAppendix E、[ISO8601]のセクション3、および適切なITUドキュメント[ITU-R TF]を見てください。
3. Two Digit Years
3. 2ケタ年
The following requirements are to address the problems of ambiguity of 2-digit years:
以下の要件は2ケタの年のあいまいさのその問題を訴えることです:
o Internet Protocols MUST generate four digit years in dates.
o インターネットプロトコルは日付における4ケタ年発生させなければなりません。
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 2ケタの年の使用は推奨しないです。 2ケタの年が受け取られていて、不正確な解釈がプロトコルか処理失敗を引き起こすだけではないなら(例えば、目的を登録するか、またはたどるのにだけ使用されるなら)、それを受け入れるべきです。
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 2ケタを使用するプログラムが年間3ケタとして1999の何年も後を表すのは、可能です。 プログラムが1年から1900を単に引き算して、ケタの数をチェックしないなら、これは起こります。 そのような壊れているソフトウェアで発生する日付に強壮に対処したがっているプログラムは1900〜3ケタ年を加えるかもしれません。
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 「2ケタを使用するプログラムが年間」 : 0インチとして1999の何年も後を表すのは、可能である」: 1インチ… ":9", ";0", ... プログラムが1年から1900を単に引き算して、米国-ASCII文字ゼロに10年間を加えるなら、これは起こります。 そのような壊れているソフトウェアで発生する日付に強壮に対処したがっているプログラムは、適切に非数値の数10年間を検出して、解釈するはずです。
The problems with two digit years amply demonstrate why all dates and times used in Internet protocols MUST be fully qualified.
2ケタ年に関する問題は十分に、完全にインターネットプロトコルに使用されるすべての日付と回に資格がなければならない理由を示します。
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)を使用することによって本当の相互運用性を達成するのは最も良いです。 この仕様は現地時間までゾーン規則を仕出ししません。
Klyne, et. al. Standards Track [Page 4] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[4ページ]: タイムスタンプ2002年7月
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])に、地方のオフセットは、迅速な応答の確率を測定するために役に立つヒューリスティックを提供します。 [HOST-REQ]、欧字列で地方のオフセットをラベルする試みは過去の[IMAIL]で貧しい相互運用性をもたらしました。 その結果、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.)
数値オフセットは「UTCを引いて現地時間」として計算されます。 それで、UTCの同等な時間は、現地時間からオフセットを引き算することによって、決定できます。 例えば、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.
以下に注意してください。 ISO8601に続いて、数値オフセットは整数の数分までに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: 0インチ」 「これは」 「Z」か+00のオフセットと意味的に異なっています: 0インチ。(その0インチはUTCが指定された時間の都合のよい基準点であることを含意します)。 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に気づきません。 インターネットには仕様を作成するとき現実を受け入れる伝統がある間、相互運用性を犠牲にしてこれをするべきではありません。 ゾーンがおよそ23/24の地球に失敗する資格のない現地時間の解釈以来、資格のない現地時間の相互運用性問題はインターネットに容認できないと考えられます。 現地時間の1時によって構成されて、対応するUTCオフセットに気づかなく、他のインターネット・システムで時間同期化によるシステムはUTCとの正しい同期を確実にするメカニズムを使用しなければなりません。 いくつかの適当なメカニズムは以下の通りです。
o Use Network Time Protocol [NTP] to obtain the time in UTC.
o Network Timeプロトコル[NTP]を使用して、UTCで時間を得てください。
Klyne, et. al. Standards Track [Page 5] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[5ページ]: タイムスタンプ2002年7月
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 インターネットへのゲートウェイと同じ現地時間のゾーンで別のホストを使用してください。 このホストは他のホストに伝えられる資格のない現地時間を修正しなければなりません。
o Prompt the user for the local time zone and daylight saving rule
settings.
o 現地時間の間のユーザのためにゾーンと日光の節約規則設定をうながしてください。
5. Date and Time format
5. 日付とTime形式
This section discusses desirable qualities of date and time formats and defines a profile of ISO 8601 for use in Internet protocols.
このセクションは、日時の形式の望ましい品質について論じて、インターネットプロトコルにおける使用のためにISO8601のプロフィールを定義します。
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.
最も正確でないのから最も正確になるまで日時のコンポーネントを注文するなら、役に立つ特性を獲得します。 「日付と現代の時間帯が同じストリング(例えばすべての「Z」かすべて」+00: 0インチ)を使用することで言い表される同じくらい(例えば、すべてUTCの)、すべての回が同じ数の第2断片的なケタを持っているということであると仮定する場合、ストリング(例えば、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]の日付の形式は、人々が、どんなテキスト文字列も受入れられたと仮定したとき、相互運用性問題をもたらして、3つの手紙略語を他の言語に翻訳するか、または、より発生しやすかった日付の形式(例えばC機能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。日付を場所に適したシステム出力表示形式に変えるように用意してください。 これは、現地時間までUTCを翻訳するのを含むかもしれません。
Klyne, et. al. Standards Track [Page 6] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[6ページ]: タイムスタンプ2002年7月
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.
以下で定義された書式は1つのめったに使用されなかったオプションだけを含んでいます: 1秒の何分の一。 これが単に日付/タイムスタンプの厳しい注文を必要とするか、または珍しい精度要件を持っているアプリケーションで使用されると予想されます。
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.
日付/時間形式が余分な情報を含んでいるなら、それは余分な情報が関連しない可能性を導入します。 例えば、日付/時間形式で曜日を含んでいると、週の曜日が不正確である可能性は導入されますが、期日は適度であるか、逆もまた同様です。 日付からの週の曜日を計算するのが難しくないので(Appendix Bを見てください)、日付/時間形式で週の曜日を含むべきではありません。
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.
ISO8601[ISO8601]で指定された完全な日時の形式は複数の表現と部分的な表現を提供する試みでかなり複雑です。 付録AはISO8601の完全な構文をABNFに翻訳する試みを含んでいます。 インターネットプロトコルには、いくらか異なった要件があります、そして、簡単さは重要な特性であると判明しました。 さらに、通常、インターネットプロトコルは、本当の相互運用性を達成するためにデータの完全な仕様を必要とします。 したがって、ISO8601のための完全な文法はほとんどのインターネットプロトコルには複雑過ぎると考えられます。
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.
以下のセクションはインターネットにおける使用のためにISO8601のプロフィールを定義します。 それはISO8601拡張フォーマットのconformant部分集合です。 簡単さは、ほとんどの分野と句読点を義務的にすることによって、達成されます。
Klyne, et. al. Standards Track [Page 7] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[7ページ]: タイムスタンプ2002年7月
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].
ISO8601[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
日付-fullyearは4DIGIT日付-月=2DIGITと等しいです。 01-12 日付-mdayは2DIGITと等しいです。 01-28 01-31 01-29と、01-30にベース。 月/年の時間-時間は2DIGITと等しいです。 00-23 時間-分は2DIGITと等しいです。 00-59 時間-2番目は2DIGITと等しいです。 00-58に、00-59に、00-60は閏秒を基礎づけました。 「時間-secfrac=を統治する」、」 「1*DIGITは-numoffsetに=(「+」/「-」)時間-時間を調節する」:、」 時間-分時間オフセット=時間「Z」/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
「部分的な時間=時間-時間」:、」 「時間-分」:、」 時間-第2[時間-secfrac]=日付-fullyear「-」日付-月の「-」日付-mdayの完全な期日フルタイムの=部分的な時間時間オフセット
date-time = full-date "T" full-time
日付-時間は常勤に完全な期日の「T」と等しいです。
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.
この日付/時間形式は''--'Z'という上側の、そして、小文字の手紙と'a'を見分けるいくつかの環境か文脈で使用されるかもしれません--'z'(例えば、XML)。 そのような環境でこの形式を使用する仕様がさらに日付/時間構文を制限するかもしれないので、いつも'T'と'Z'が日付/時間構文で使用した手紙は大文字であるに違いありません。 この形式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.
以下に注意してください。 「T」によって切り離されて、ISO8601は日時を定義します。 この構文を使用するアプリケーションは選ばれるかもしれません、読み易さのために完全な期日でフルタイムで指定するのは(言います)間隔文字で分離しました。
Klyne, et. al. Standards Track [Page 8] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[8ページ]: タイムスタンプ2002年7月
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:
文法要素日付-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
Number Month/年のMaximumが評価する日付-mdayの月------------ ---------- -------------------------- 2031年1月1日の2月02日、正常な28 02 2月、2031年5月5日の2030年6月6日2031年7月7日の2031年8月8日2030年9月9日の2031年10月10日2030年11月11日の2031年12月12日2031年3月3日の2030年4月4日のうるう年29
Appendix C contains sample C code to determine if a year is a leap year.
付録Cは1年がうるう年であるなら決定するサンプル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).
文法要素時間-秒には、値「閏秒は起こります--以下とデートするために何カ月もの終わりの60インチ」があるかもしれません。 6月(XXXX-06- 30T23:59:60Z)か12月(XXXX-12-31T23:59:60Z)。 飛躍秒のテーブルのためにAppendix Dを見てください。 また、閏秒が引き算されるのも、可能です、時間-2番目の最大値が「58インチ」であるというどの時に。 他のすべての回、時間-2番目の最大値は「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.
遠くに未来まで飛躍秒を予測できません。 Rotation Serviceの国際地球は数週間の警告で飛躍秒を発表する報告[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.
そして、ISO8601が、時間は可能にする、「何24インチも、ISO8601のこのプロフィールが値を許容するだけである、「0インチ、「時間の23インチ、混乱を抑える、」
Klyne, et. al. Standards Track [Page 9] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[9ページ]: タイムスタンプ2002年7月
5.8. Examples
5.8. 例
Here are some examples of Internet date/time format.
ここに、インターネット日付/時間形式に関するいくつかの例があります。
1985-04-12T23:20:50.52Z
1985-04-12 T23:20:50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of April 12th, 1985 in UTC.
これは20分と4月の23時間目の50.52秒後に12番目、UTCの1985を表します。
1996-12-19T16:39:57-08:00
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.
これが12月の16時間目の39分と57秒後に19番目、オフセットがある1996を表す、-08:00 UTC(太平洋標準時の)から。 これがUTCで1996-12-20 T00:39:57Zに同等であることに注意してください。
1990-12-31T23:59:60Z
1990-12-31 T23:59:60Z
This represents the leap second inserted at the end of 1990.
これは1990年の終わりに挿入された閏秒を表します。
1990-12-31T15:59:60-08:00
1990-12-31T15: 59:60-08:00
This represents the same leap second in Pacific Standard Time, 8 hours behind UTC.
これはUTCの8時間後ろで太平洋標準時に同じ閏秒を表します。
1937-01-01T12:00:27.87+00:20
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.
これは1937年1月1日に時の同じ瞬間に正午としてオランダ時間を表します。 オランダの標準時が19分とUTCのちょうど32.13秒前に法であった、1909年から1905年まで、-01、1937年6月30日まで。 まさにHH: MM形式を使用することでこの時間帯を表すことができません、そして、このタイムスタンプは最も厳密なrepresentable UTCオフセットを使用します。
6. References
6. 参照
[ZELLER] Zeller, C., "Kalender-Formeln", Acta Mathematica, Vol.
9, Nov 1886.
[ツェラー]ツェラー、C.、"Kalender-Formeln"、訴訟手続きマテマテイカ、Vol.9、1886年11月。
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet
Text Messages", STD 11, RFC 822, August 1982.
[IMAIL] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[IMAIL-UPDATE] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[IMAIL-アップデート] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
Klyne, et. al. Standards Track [Page 10] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[10ページ]: タイムスタンプ2002年7月
[ISO8601] "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO
8601:1988(E), International Organization for
Standardization, June, 1988.
[ISO8601] 「データ要素と置き換え形式--情報交換--日付と回の表現」、ISO8601: 1988(E)、国際標準化機構(1988年6月)。
[ISO8601:2000] "Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO
8601:2000, International Organization for
Standardization, December, 2000.
「データ要素と置き換えは日付と回の表現をフォーマットします(情報交換)」、ISO。[ISO8601:2000]、8601:2000 国際標準化機構(2000年12月)。
[HOST-REQ] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October
1989.
ブレーデン、[ホスト-REQ]R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[IERS] International Earth Rotation Service Bulletins,
<http://hpiers.obspm.fr/eop-
pc/products/bulletins.html>.
[IERS]国際地球Rotation Service Bulletins、<http://hpiers.obspm.fr/eop- pc/製品/bulletins.html>。
[NTP] Mills, D, "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[NTP] 工場、D、「ネットワーク時間は仕様、実現、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[ITU-R-TF] International Telecommunication Union Recommendations
for Time Signals and Frequency Standards Emissions.
<http://www.itu.ch/publications/itu-r/iturtf.htm>
[ITU-R-TF] 時報のための国際電気通信連合の推薦と頻度規格放出。 <http://www.itu.ch/刊行物/itu-r/iturtf.htm>。
[RFC2119] Bradner, S, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
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.
サイトの現地時間のゾーンがシステムが、よりモニターされそうにない時を決定することの役に立つかもしれなくて、セキュリティ徹底的調査により影響されやすいかもしれないので、いくつかのサイトがUTCだけで回を放ちたがっているかもしれません。 他のものは、これがパラノイアの手における役に立つ機能性の損失であると考えるかもしれません。
Klyne, et. al. Standards Track [Page 11] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[11ページ]: タイムスタンプ2002年7月
Appendix A. ISO 8601 Collected ABNF
付録A.ISO8601はABNFを集めました。
This information is based on the 1988 version of ISO 8601. There may be some changes in the 2000 revision.
この情報は1988年のISO8601のバージョンに基づいています。 2000年の改正におけるいくつかの変化があるかもしれません。
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.
ISO8601はそれが定義する日時の書式に形式文法を指定しません。 ↓これはISO8601から形式文法を作成する試みです。 そして、これが情報である、唯一、誤りを含むかもしれません。 ISO8601は正式の参照のままで残っています。
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.
ISO8601のあいまいさのため、いくつかの解釈をしなければならなかったことに注意してください。 まず最初に、ISO8601は基本的で拡張している形式の混合物が許されるかどうか明確ではありません。 この文法は混合物を可能にします。 24の1時間が数分と秒が0である場合にだけ許されているかどうかに関してISO8601は明確ではありません。 これは、24の1時間がどんな文脈でも許されていると仮定します。 セクション5.7の日付-mdayにおける制限は適用されます。 ISO8601は、「T」がいくつかの状況で省略されるかもしれないと述べます。 この文法は、あいまいさを避けるために「T」を必要とします。 また、ISO8601が必要である、(コネセクション5.3.1.3、)小数はaによって続かされる、「0インチ、統一よりそれほど」 ISO8601の別館B.2は小数が「0インチ」先行されていない例を出します。 この文法は、セクション5.3が.1であると仮定します。.3は正しいです、そして、Annex B.2は間違っています。
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
日付-世紀は2DIGITと等しいです。 00-99 日付-10年間はDIGITと等しいです。 0-9 日付-「副-10年間」はDIGITと等しいです。 0-9 日付-年=日付-10年間日付-「副-10年間」日付-fullyearは日付の世紀日付の年の日付-月=2DIGITと等しいです。 01-12 日付-wdayはDIGITと等しいです。 1-7 ; 1が月曜日である、7は日曜日の日付-mday=2DIGITです。 01-28 01-31 01-29と、01-30にベース。 月/年の日付-ydayは3DIGITと等しいです。 001-365 001-366は年に日付-週の=2DIGITを基礎づけました。 01-52に、01-53に、年に基づいています。
datepart-fullyear = [date-century] date-year ["-"] datepart-ptyear = "-" [date-subdecade ["-"]] datepart-wkyear = datepart-ptyear / datepart-fullyear
datepart-fullyear=[日付-世紀]日付-年[「-」]datepart-ptyear=「-」[日付-「副-10年間」[「-」]]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 ["-"])
(日付-月[「-」])dateopt-週=(日付-年の[「-」])dateopt-月=datepart-fullyear dateopt-年=日付-世紀dateopt-fullyear=dateopt-世紀=「-」/「-」/「-」/「-」/「-」/(日付-週の[「-」])
Klyne, et. al. Standards Track [Page 12] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[12ページ]: タイムスタンプ2002年7月
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
「datespec完全な=datepart-fullyear日付-月[「-」]日付のmday datespec=日付-世紀/dateopt世紀日付の年datespec-月の=「-」dateopt-年の日付-月[[「-」]日付-mday]のdatespec-mday=「--」dateopt-月の年日付のmday datespec週=datepart-wkyear「W」(日付-週の/dateopt-週日付-wday)datespec-wday=」---「日付-wday datespec-ydayはdateopt-fullyear日付-ydayと等しいです」
date = datespec-full / datespec-year
/ datespec-month /
datespec-mday / datespec-week / datespec-wday / datespec-yday
日付=datespec完全な//datespec-月のdatespec-年/datespec-mday/datespec-週/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
時間-時間は2DIGITと等しいです。 00-24 時間-分は2DIGITと等しいです。 00-59 時間-2番目は2DIGITと等しいです。 00-58 00-60 00-59にベース。 「閏秒に時間断片=を統治する、(「」 /」、」、)、1*けた時間numoffsetな=(「+」/「-」)時間-時間、[「:」、]、時間-分] 時間帯は時間「Z」/numoffsetと等しいです。
timeopt-hour = "-" / (time-hour [":"]) timeopt-minute = "-" / (time-minute [":"])
timeopt時間=「-」/、(時間-時間、[「:」、)、timeoptに=「-」/を書き留めてください。(時間-分、[「:」、)
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
timespec-一時間=時間-時間、[「:」、]、時間-分、[「:」、]、時間-秒]timespec-分=timeopt-一時間時間-分、[「:」、]、時間-秒] timespec-2番目はtimespec-時間「-」のtimeopt-分時間-第2timespec-ベース=/とtimespec微小であるかtimespec2番目であることで等しいです。
time = timespec-base [time-fraction] [time-zone]
時間=timespec-ベース[時間断片][時間帯]
iso-date-time = date "T" time
iso日付の時間=「T」時間日付
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]
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-時間]
duration = "P" (dur-date / dur-time / dur-week)
持続時間は「P」と等しいです。(dur dur-日付/時間/dur-週)
Klyne, et. al. Standards Track [Page 13] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[13ページ]: タイムスタンプ2002年7月
Periods:
期間:
period-explicit = iso-date-time "/" iso-date-time period-start = iso-date-time "/" duration period-end = duration "/" iso-date-time
」 日付の期間が始動するiso=iso日付「期間の明白な=iso日付時間」/時間、」 /、」持続時間期間-終わりが持続時間と等しい、」 /、」iso日付の時間
period = period-explicit / period-start / period-end
期間=期間期間の明白な/期間始め/終了
Appendix B. Day of the Week
付録B.曜日
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:
↓これは0000-03-01か0000-03-01の後に曜日を日付に得るのに使用されるかもしれない緩くツェラーのCongruence[ツェラー]に基づくサンプルCサブルーチンです:
char *day_of_week(int day, int month, int year)
{
int cent;
char *dayofweek[] = {
"Sunday", "Monday", "Tuesday", "Wednesday",
"Thursday", "Friday", "Saturday"
};
_週(int日、int月、int年)の*日_を炭にしてください、intセント; 「日曜日」、「月曜日」、「火曜日」、「水曜日」、「木曜日」、「金曜日」、「土曜日」のときに*dayofweek[]=を炭にしてください。
/* 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]);
}
/*が月の間、適応するので、2月は最後の1*/月の-=2です、。 (月<1)である、月+=12;、--年;、/*は世紀で=年/100*/セント分かれました。 年の%=100。 戻ってください(dayofweek(26*月--4+セント/4+5+ 年/の2)/10+日+年*セント)%7)。 }
Appendix C. Leap Years
付録C.うるう年
Here is a sample C subroutine to calculate if a year is a leap year:
ここに、計算するサンプルCサブルーチンが1年がうるう年であるならあります:
/* 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));
}
これが年であるなら非ゼロを返す/*はうるう年です。 4ケタ年を費やさなければなりません。 */int飛躍_年(int年)リターン、(年の%4 == 0、(%100!が0と等しい年| | 年の%400 == 0)。
Klyne, et. al. Standards Track [Page 14] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[14ページ]: タイムスタンプ2002年7月
Appendix D. Leap Seconds
付録D.飛躍秒
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.
UTCで閏秒を導入するという決定はRotation Serviceの国際(IERS)地球の責任です。 CCIR Recommendationによると、12月、6月の終わり、および3月、9月の終わりのそれらへの2番目の好みで最優先を機会に与えます。
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に関するタイムスタンプで表されたUTCの1日の余分な秒終わりのように起こります。 閏秒が同時にすべての時間帯で起こるので、時間帯の関係は影響を受けません。 閏秒回のいくつかの例に関してセクション5.8を見てください。
The following table is an excerpt from the table maintained by the United States Naval Observatory. The source data is located at:
以下のテーブルは合衆国Naval Observatoryによって維持されたテーブルからの抜粋です。 ソースデータは以下に位置しています。
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>
<ftp://maia.usno.navy.mil/ser7/tai-utc.dat>。
Klyne, et. al. Standards Track [Page 15] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[15ページ]: タイムスタンプ2002年7月
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.
このテーブルには、その閏秒の後に、閏秒の日付と、時間の標準のTAI(飛躍秒までに調整されない)とUTCの差異があります。
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
UTC日付TAI--閏秒の後のUTC-------- --------------------------- 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
Klyne, et. al. Standards Track [Page 16] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[16ページ]: タイムスタンプ2002年7月
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.
以下の人々はこのドキュメントの以前の肉体化に有益な助言を提供しました: 解放されたネッド、ニールMcBurnett、デヴィッドKeegel、マーカス・キューン、ポール・エッゲルト、およびロバートElz。 感謝はIETF Calendaring/スケジューリングワーキンググループメーリングリストの関係者、および時間帯のメーリングリストの関係者のもためです。
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.
以下の評論家は現在の改正のための役立つ提案を寄付しました: トムHarsch、マーカス・キューン、ピートレズニック、ダン・コーン。 ポール・エッゲルトは飛躍秒と時間帯のオフセットの微妙さに関して多くの慎重な観測を提供しました。 以下の人々は修正と以前の草稿への改良に注意しました: ジョン・ストックトン博士、ユッタDegener、ジョーAbley、およびダンは飛んで行きます。
Authors' Addresses
作者のアドレス
Chris Newman Sun Microsystems 1050 Lakes Drive, Suite 250 West Covina, CA 91790 USA
クリスニューマンサン・マイクロシステムズ1050湖ドライブ、Suite250ウエストコビナ、カリフォルニア91790米国
EMail: chris.newman@sun.com
メール: chris.newman@sun.com
Graham Klyne (editor, this revision) Clearswift Corporation 1310 Waterside Arlington Business Park Theale, Reading RG7 4SA UK
グラハムKlyne(エディタ、この改正)Clearswift社1310のWatersideアーリントンBusiness Park Theale、Reading RG7 4SAイギリス
Phone: +44 11 8903 8903 Fax: +44 11 8903 9000 EMail: GK@ACM.ORG
以下に電話をしてください。 +44 11 8903 8903、Fax: +44 11 8903 9000はメールされます: GK@ACM.ORG
Klyne, et. al. Standards Track [Page 17] RFC 3339 Date and Time on the Internet: Timestamps July 2002
et Klyne、アル。 規格はインターネットで3339年のRFC日時を追跡します[17ページ]: タイムスタンプ2002年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klyne, et. al. Standards Track [Page 18]
et Klyne、アル。 標準化過程[18ページ]
一覧
スポンサーリンク
