Loading article…
| 日付 | 2024-12-05 |
|---|---|
| UTC時間 | 02:20:37Z T022037Z |
| UTCでの日付と時刻 | 2024-12-05T02:20:37Z 20241205T022037Z |
| オフセット付きの日付と時刻 | 2024-12-04T14:20:37−12:00 UTC−12:00 [更新] 2024-12-05T02:20:37+00:00 UTC+00:00 [更新] |
| 週 | 2024-W49 |
| 曜日を含む週 | 2024-W49-4 |
| 序数日付 | 2024‐340 |
ISO 8601は、日付と時刻に関連するデータの世界的な交換と通信をカバーする国際標準です。国際標準化機構（ISO）によって管理されており、1988年に最初に発行され、1991年、2000年、2004年、2019年に更新され、2022年に修正されました。[1]この標準は、世界的な通信でカレンダーの日付と時刻を表すための明確で明確な方法を提供し、特に、数値の日付と時刻の表記方法が異なる国間でデータを転送する場合に、数値の日付と時刻の誤解を避けるのに役立ちます。
ISO 8601 は、次の表現と形式に適用されます:グレゴリオ暦 (先発グレゴリオ暦を含む)の日付、 24 時間制に基づく時刻( UTC オフセットをオプションで使用) 、時間間隔、およびそれらの組み合わせ。[2]この規格では、表現される日付/時刻のどの要素にも特定の意味を割り当てていません。どの要素の意味も、その使用状況によって異なります。表現される日付と時刻には、規格内で特定の数値的意味を持たない単語 (したがって、中国暦の年名は除く)、またはコンピューター文字を使用しない単語(画像や音声は除く) は使用できません。[2]
ISO 8601交換標準に準拠した表現では、日付と時刻は、最も長い時間的用語 (通常は年) が左側に配置され、それより短い各用語が前の用語の右側に配置されるように配置されます。表現は、アラビア数字と、標準内で特定の意味が割り当てられている特定のコンピュータ文字 (「‐」、「:」、「T」、「W」、「Z」など) の組み合わせで記述する必要があります。つまり、「1 月」、「木曜日」、「元日」などの一般的な日付 (または日付の一部) の記述子は、標準内の交換表現では許可されません。
歴史
ISO 8601規格の初版は、1988年にISO 8601:1988として発行されました。これは、日付と時刻の表記のさまざまな側面に関するいくつかの古いISO規格（ ISO 2014、ISO 2015、ISO 2711、ISO 3307、およびISO 4031）を統合して置き換えました。[3]これは、2000年に第2版ISO 8601:2000に置き換えられ、2004年12月1日に発行された第3版ISO 8601:2004に置き換えられ、2019年2月25日にISO 8601-1:2019およびISO 8601-2:2019によって撤回および改訂されました。ISO 8601は、 [4] ISO技術委員会TC 154によって作成され、直接の責任を負っています。[5]
ISO 2014 は、置き換えられましたが、最上位から最下位の順序ですべて数字による日付表記法[YYYY]-[MM]-[DD] を最初に導入した標準です。ISO 週番号付けシステムは ISO 2015 で導入され、序数による日付の識別は ISO 2711 で最初に定義されました。
2019年2月に発行された[6] ISO 8601-1:2019規格の第4版は、以前のISO 8601:2004規格の内容をわずかに更新したもので、[7] [8]新しいISO 8601-2:2019では、不確実性や拡張日付/時刻形式（EDTF）の一部など、さまざまな拡張機能が定義されています。[9] [10] [11] [12] [13] [14]
2022 年 10 月に、技術的な軽微な明確化と定義の曖昧さの排除を目的とした修正が発表されました。しかし、最も重要な変更点は、暦日の 終わりの瞬間を示すために「24:00:00」形式が再導入されたことです。
一般原則
- 日付と時刻の値は、年、月 (または週)、日、時、分、秒、秒未満の順に並べられます。したがって、表現の辞書式順序は、負の年または時間オフセットを含む日付表現を除いて、時系列順序に対応します。これにより、たとえばファイル システムによって日付を自然に並べ替えることができます。
- 各日付と時刻の値には固定の桁数があり、先頭にゼロを埋め込む必要があります。
- 表現は、区切り文字を最小限にした基本形式、または人間の可読性を高めるために区切り文字を追加した拡張形式の2 つの形式のいずれかで行うことができます。 [15] [16]標準では、「プレーンテキストでは基本形式を避ける必要があります。」と記載されています。 [17]日付値 (年、月、週、日) 間の区切り文字にはハイフンが使用され、時刻値 (時、分、秒) 間の区切り文字にはコロンが使用されます。たとえば、2009 年 1 月 6 日は、拡張形式では「2009-01-06」と記述できますが、基本形式では「20090106」と記述しても曖昧さはありません。
- 精度を低下させる場合、[18]任意の数の値を任意の日付と時刻の表現から削除できますが、最小値から最大値の順序になります。たとえば、「2004-05」は有効な ISO 8601 日付であり、2004 年 5 月 (5 番目の月) を示します。この形式では、2004 年の指定されていない月の 5 日目を表すことはなく、2004 年から 2005 年までの期間を表すこともありません。
- 特定のアプリケーションで必要な場合、標準では、表現内の最小の時間値に小数点を追加することをサポートしています。
日付
この規格ではグレゴリオ暦が採用されており、「民間使用のための国際標準として機能」している。[19]
ISO 8601:2004 では、1875 年 5 月 20 日のグレゴリオ暦を基準暦日として、パリでメートル条約(メートル条約) が調印された日と定めています(明示的な基準日は ISO 8601-1:2019 で削除されました)。ただし、条約以前の ISO 暦の日付は、グレゴリオ暦が正式に導入された 1582 年 10 月 15 日まで遡って、グレゴリオ暦と互換性があります。
情報交換を行うパートナー間の合意により、先発グレゴリオ暦のそれより前の日付が使用される場合があります。標準ではすべての日付が連続している必要があると規定されているため、ユリウス暦の使用は標準に反します (切り替え日には日付が連続していないため)。
年
| ええ |
| ± Y YYYY |
ISO 8601 では、 2000 年問題を回避するために、最低でも 4 桁の年 [YYYY] を規定しています。したがって、これは 0000 から 9999 までの年を表し、0000 年は紀元前1 年、その他は西暦に相当し、天文学的な年番号付けに似ています。ただし、1583 年 (グレゴリオ暦導入後の最初の完全な年) より前の年は、標準では自動的に許可されません。代わりに、標準では、「[0000] から [1582] までの範囲の値は、情報交換のパートナーの相互合意によってのみ使用されるものとする」と規定されています。[20]
0000より前または9999より後の年を表すために、標準規格では年表現の拡張も許可していますが、送信者と受信者の間で事前に合意されている場合に限られます。[21]拡張された年表現 [± Y YYYY] は、最小 4 桁を超える合意された数の追加年桁を持つ必要があり、より一般的なAD/BC (またはCE/BCE ) 表記の代わりに+ または - 記号を前に付ける必要があります[22]。慣例により、1 BC は+0000、2 BC は -0001 というようにラベル付けされます。[23]
カレンダーの日付
| 年-月-日 | または | 年月日 |
| 年-月 | (ただしYYYYMMではありません) | |
| 2000年版（現在は廃止）でのみ許可されている：[24] | ||
| 年-月-日 | または | 年月日 |
| -年-月 | または | -年月日 |
| --月-日 | または | --MMDD |
| --MM | ||
| ---DD | ||
カレンダーの日付の表現は、隣のボックスに示されている形式です。[YYYY]は4桁の年（0000～9999）を示します。[MM]は2桁の月（01～12）を示します。[DD]はその月の2桁の日（01～31）を示します。たとえば、「1981年4月5日」は、拡張形式では「1981-04-05」[15] 、基本形式では「19810405」と表されます。
この標準では、精度を下げてカレンダーの日付を記述することもできます。たとえば、「1981-04」と書いて「1981年4月」という意味になります。単に「1981」と書いてその年を指すこともできますし、「198」と書いて1980年から1989年までの10年間を指すこともできますし、「19」と書いて1900年から1999年までの世紀を指すこともできます。この標準では、カレンダーの日付を完全に表すために「YYYY-MM-DD」とYYYYMMDDの両方の形式が認められていますが、日[DD]が省略されている場合はYYYY-MM形式のみが許可されます。YYYYMM形式の日付を禁止することで、この標準では切り捨て表現[1] [3] YYMMDD（今でもよく使用されています）との混乱を回避しています。 2000年版では、 「4月5日」を意味する「--04-05」という切り捨て表記も許可されていたが[25]、2004年版では月が存在する場合に年を省略することは許可されていない。
例:
- 2000年1月7日は「2000-01-07」または「20000107」と表記されます。
週の日付
| YYYY-Www | または | ええええええええええええええええええ |
| YYYY-Www-D | または | YYYYWwwD |
週の日付の表現は、隣のボックスに示されている形式です。[YYYY] は、従来のグレゴリオ暦の年とは少し異なるISO 週番号の年を示します(以下を参照)。[Www] は、先頭に文字Wが付く週番号で、W01 から W53 までです。[D] は、月曜日から始まり日曜日で終わる 1 から 7 までの 曜日番号です。
週 01 には、相互に同等かつ互換性のある説明がいくつかあります。
- 開始年の最初の営業日を含む週（土曜日、日曜日、1月1日は休業日とみなします）、
- 開始年の最初の木曜日を含む週（正式なISO定義）、
- 1月4日を含む週
- 開始年の最初の週で、その日数の大半（4日以上）があり、
- 12月29日から1月4日までの期間の月曜日から始まる週。
その結果、1 月 1 日が月曜日、火曜日、水曜日、または木曜日の場合、週 01 になります。1 月 1 日が金曜日、土曜日、または日曜日の場合、前年の週 52 または 53 になります (週 00 はありません)。12 月 28 日は常にその年の最終週になります。
週番号は木曜日を数えることで表すことができます。つまり、週 12 にはその年の 12 番目の木曜日が含まれます。
ISO週番号年は、週 01 の最初の日 (月曜日) から始まり、新しい ISO 年の前日の日曜日に終わります (したがって、重複やギャップはありません)。52 週または 53 週で構成されます。年の最初の ISO 週には、終了するグレゴリオ暦の年に含まれる日が最大 3 日ある場合があります。3 日ある場合、その日数は月曜日、火曜日、水曜日です。同様に、年最後の ISO 週には、開始するグレゴリオ暦の年に含まれる日が最大 3 日ある場合があります。3 日ある場合、その日数は金曜日、土曜日、日曜日です。各 ISO 週の木曜日は、常に ISO 週番号年で示されるグレゴリオ暦の年になります。
例:
- 2008年12月29日月曜日は「2009-W01-1」と書かれています
- 2010年1月3日日曜日は「2009-W53-7」と書かれています
序数日付
| 年-月 | または | 年 |
序数日付は、年初からの経過日数の倍数を表す序数形式です。これは「YYYY-DDD」（または YYYYDDD）として表されます。ここで、[YYYY] は年を示し、[DDD] は「年間通算日」で、001 から 365（閏年の場合は 366 ）までです。たとえば、「1981-04-05」は「1981-095」と同じです。
この単純な形式は、週と月の定義の恣意性が助けになるよりもむしろ障害になる場合、たとえば異なる暦の日付を比較する場合に適しています。この形式は、日付システムが必要な単純なハードウェア システムで使用されますが、完全な暦計算ソフトウェアを含めると非常に面倒な場合があります。このシステムは「ユリウス日」と呼ばれることもありますが、これは、ユリウス先発暦の紀元前4713 年 1 月 1日のグリニッジ正午 (または、グレゴリオ先発暦を 0000 年とする ISO 日付-4713-11-24の正午)を 0 日目として、日数を連続してカウントする天文学上のユリウス日と混同される可能性があります。
タイムズ
| 木:月:ss.sss | または | んんんっ |
| 木:月:日 | または | んー |
| 木:んんん | または | うーん、うーん |
| んー | または | うーん |
| ああ、ああ | ||
| た | ||
| 明確な文脈において | ||
| 時:分:秒.秒 | または | うーん、うーん |
| 時:分:秒 | または | うーん |
| 時:分 | または | うーん |
| はあ | ||
ISO 8601 では24 時間制が採用されています。ISO 8601-1:2019 では、基本形式は T[hh][mm][ss]、拡張形式は T[hh]:[mm]:[ss] です。以前のバージョンでは、両方の形式で T (時間を表す) が省略されていました。
- [hh] は 00 から 24 までのゼロ埋めされた時間を表します。
- [mm]は00から59までのゼロ埋めされた分を表します。
- [ss] は 00 から 60 までのゼロ埋め秒を表します (60 は追加されたうるう秒を示すためだけに使用されます)。
したがって、時刻は、基本形式では「T134730」、拡張形式では「T13:47:30」と表示されます。 ISO 8601-1:2019 では、拡張形式では「13:47:30」のように T を省略できますが、基本形式では日付表現と混同するリスクがない場合にのみ T を省略できます。
基本形式または拡張形式から秒または分と秒を省略すると、簡潔になりますが精度は低下します。その結果、精度が低下した時間形式は次のようになります。[26]
- 秒を省略した場合、基本形式ではT[hh][mm] 、拡張形式ではT[hh]:[mm]になります。
- T[hh]、秒と分の両方が省略されている場合。
ISO 8601-1:2019/Amd 1:2022 では、「00:00:00」は暦日の開始時点に対応する真夜中を指すのに使用でき、「24:00:00」は暦日の終了時点に対応する真夜中を指すのに使用できます。 [1]当初発行された ISO 8601-1:2019 では、標準の以前のバージョンでは許可されていましたが、一日の終わりの表現として「24:00:00」が削除されました。
これらの表現のいずれにおいても、最も低い位の時間要素に小数点を追加することができます。小数点記号（ベースライン上のカンマまたはドット）は、時間要素とその小数点の間の区切りとして使用されます。（ISO 8601:1-2019に従ってISO 80000-1に従うと、 [27]国際標準以外では優先順位は規定されていませんが、ISO 8601:2004に従ってカンマが優先されます。 [28]）たとえば、「14時間30分30秒」を表すには、秒の数字を含めず、「14:30,5」、「T1430,5」、「14:30.5」、または「T1430.5」と表します。
小数点以下の桁数に制限はありません。ただし、小数点以下の桁数は通信当事者間で合意する必要があります。たとえば、Microsoft SQL Server では、 DATETIME の小数点以下の精度は 3 です (つまり、「yyyy-mm-ddThh:mm:ss[.mmm]」)。[29]
タイムゾーン指定子
| <時間>Z |
| <時間>±hh:mm |
| <時間>±hhmm |
| <時間>±hh |
ISO 8601 のタイムゾーンは、ローカル時間 (場所は指定されません)、UTC、または UTC からのオフセットとして表されます。
現地時間（無条件）
時間表現に UTC 関係情報が指定されていない場合、時間は現地時間であるとみなされます。同じタイムゾーンで通信する場合は現地時間とみなしても問題ありませんが、異なるタイムゾーン間で通信する場合はあいまいになります。単一の地理的タイムゾーン内であっても、その地域で夏時間が実施されている場合は現地時間があいまいになります。通常は、標準の表記法を使用してタイムゾーン (ゾーン指定子) を示すことが望ましいです。
協定世界時 (UTC)
時刻がUTCの場合は、スペースなしで時刻の直後にZ を追加します。ZはUTC オフセットのゼロを示すゾーン指定子です。したがって、「09:30 UTC」は「09:30Z」または「T0930Z」と表されます。「14:45:15 UTC」は「14:45:15Z」または「T144515Z」と表されます。
ISO 8601 の時間表記におけるZの接尾辞は、ズールー時間帯の指定に同じ文字が使用されているため、「ズールー時間」または「ズールー子午線」と呼ばれることがあります。[30]しかし、軍用時間帯のリストを定義する ACP 121 標準では UTC については触れられておらず、「ズールー時間」はかつて国際民間時間標準として使用されていたグリニッジ標準時[31]から派生しています。GMT はもはや科学界によって正確に定義されておらず、文脈に応じて UTC またはUT1のいずれかを指すことがあります。[32]
UTCからの時間オフセット
UTCオフセットは、上記の「Z」サフィックスの代わりに時間に直接追加されます。他の海事タイムゾーン文字は使用されません。オフセットはUTCに適用され、指定されたタイムゾーンの常用時間が'±[hh]:[mm]'、'±[hh][mm]'、または '±[hh]' の形式で取得されます。
負のUTC オフセットは、常用時間が UTC より遅れている本初子午線の西側のタイムゾーンを表します。したがって、ニューヨーク(標準時) のゾーン指定は、「-05:00」、「-0500」、または「-05」になります。逆に、正の UTC オフセットは、常用時間がUTCより進んでいる本初子午線の東側のタイムゾーンを表します。したがって、カイロのゾーン指定は、「+02:00」、「+0200」、または「+02」になります。
常用時間が UTC と一致するタイムゾーンは、オフセットがゼロであっても、常に正として指定されます (以下の関連仕様を参照)。したがって、ロンドン(標準時) のゾーン指定は、「 +00:00」、「+0000」、または「+00 」になります。
追加例
- ホノルル行き「−10:00」
- 標準時間のシカゴ、または夏時間のデンバーの場合は「−06:00」
- ブラジリアの場合「−03:00」
- 英国夏時間ロンドンでは「+01:00」
- ドバイは「+04:00」
- インドは「+05:30」
- 日本の場合「+09:00」
その他のUTCオフセットについては、UTC オフセットのリストを参照してください。
その他の時間オフセット仕様
ゼロ値の時間オフセットを「−00:00」、「−0000」、または「−00」のように負の符号で示すことは許可されていません。符号の使用を規定するセクションでは、正またはゼロの値にはプラス記号を使用し、負の値にはマイナス記号を使用する必要があります。プラスマイナス記号（±）も、使用可能な場合は使用できます。[33]
この規則とは対照的に、ISO 8601のプロファイルであるRFC 3339では、「+00」と同じ意味だが意味合いが異なる「-00」の使用が許可されている。つまり、UTCオフセットが不明であるということである。[34] [35]
負のオフセットを表すために、ISO 8601ではマイナス記号（−）の使用を指定しています。交換文字セットが制限されていてマイナス記号文字がない場合は、ハイフンマイナス（-）を使用する必要があります。 [36] ASCIIにはマイナス記号がないため、ハイフンマイナス文字（コード45 10）が使用されます。文字セットにUnicodeのU+2212 − MINUS SIGNなどのマイナス記号がある場合は、その文字を使用する必要があります。−のHTML文字エンティティ呼び出しはです。
−
ISO 8601-2:2019 では、時間オフセットの一般的な期間が許可されています。たとえば、次のように '<time>±[hh]:[mm]:[ss].[sss]' または '<time>±[n]H[n]M[n]S' の形式を使用して、時間オフセットにさらに精度を追加できます。
日付と時刻の表現の組み合わせ
| <日付>T<時刻> |
完全な日付表現、区切り文字としての文字「T」、および有効な時刻表現を連結することで、単一の時点を表すことができます。たとえば、「2007-04-05T14:30」です。ISO 8601:2004では、 「200704051430」のように合意により「T」文字を省略することが許可されていましたが、[37]この規定はISO 8601-1:2019で削除されました。日付と時刻の部分をスペースなどの他の文字で区切ることはISO 8601では許可されていませんが、そのプロファイルRFC 3339では許可されています。[38]
タイムゾーン指定子が必要な場合は、日付と時刻の組み合わせの後に指定します。たとえば、「2007-04-05T14:30Z」または「2007-04-05T12:30−02:00」です。
基本形式または拡張形式のいずれかを使用できますが、日付と時刻の両方で同じ形式を使用する必要があります。日付の表現は、カレンダー、週、または序数で、完全な表現を使用する必要があります。時刻は、指定された精度を下げた形式を使用して表すことができます。
期間
| 翻訳: |
| 西海岸 |
| P<日付>T<時刻> |
期間は、時間間隔内の介在時間の量を定義し、横に示すように P[n]Y[n]M[n]DT[n]H[n]M[n]S または P[n]W の形式で表されます。これらの表現では、[n] は、[n] に続く日付と時刻の各要素の値に置き換えられます。先頭のゼロは必須ではありませんが、各要素の最大桁数は通信当事者間で合意する必要があります。大文字のP、Y、M、W、D、T、H、M、およびS は、日付と時刻の各要素の指定子であり、置き換えられません。
- P は、期間表現の先頭に配置される
期間指定子 (期間用) です。
- Y は、暦年数の値に続く年指定子です。
- M は、暦月数の値に続く月指定子です。
- W は、週数の値に続く週指定子です。
- D は、暦日数の値に続く日指定子です。
- T は、表現の時間コンポーネントの前に付く時間指定子です。
- H は、時間数の値の後に続く時間指定子です。
- M は、分数の値の後に続く分指定子です。
- S は秒数の値に続く 2 番目の指定子です。
たとえば、「P3Y6M4DT12H30M5S」は、「3 年、6 か月、4 日、12 時間、30 分、5 秒」の期間を表します。
日付と時刻の要素は、その指定子を含めて、値が 0 の場合は省略できます。また、精度を低下させるために下位の要素も省略できます。たとえば、「P23DT23H」と「P4Y」はどちらも許容される期間表現です。ただし、少なくとも 1 つの要素が存在する必要があるため、「P」は 0 秒の期間を表す有効な表現ではありません。ただし、「PT0S」または「P0D」はどちらも有効であり、同じ期間を表します。
曖昧さを解消するために、「P1M」は 1 か月の期間、「PT1M」は 1 分の期間を表します (時間値の前にある時間指定子 T に注意してください)。使用される最小値には小数が含まれる場合もあります[39]。たとえば、「P0.5Y」は半年を表します。この小数は、カンマまたはピリオドで指定できます(「P0,5Y」または「P0.5Y」)。この標準では、期間表現の日付と時刻の値が「繰り越しポイント」を超えることを禁止していません (ただし、以下に説明されている場合を除く)。したがって、「PT36H」は「P1DT12H」と同様に、同じ期間を表すために使用できます。ただし、「PT36H」は、夏時間から切り替える場合や夏時間に切り替える場合、「P1DT12H」と同じではないことに注意してください。
あるいは、通信当事者間の合意により、日付と時刻を組み合わせた表現に基づく期間の形式が、基本形式 PYYYYMMDDThhmmss または拡張形式P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]のいずれかで使用されてもよい。たとえば、上記の最初の期間は「P0003-06-04T12:30:05」となる。ただし、個々の日付と時刻の値は、その係数を超えることはできない（たとえば、月の場合は13、時間の場合は25は許可されない）。[40]
標準では、期間を時間間隔の一部として説明しています。これについては次のセクションで説明します。期間の形式だけでは、暦年と暦月の合計日数に関して曖昧です。暦日の秒数も、うるう秒のため曖昧です。たとえば、「P1M」は単独では 28 日、29 日、30 日、または 31 日になります。時間間隔で使用する場合は曖昧さはありません。2 か月の暦月期間「P2M」の例:
- 間隔2003-02-15T00:00:00Z/P2Mは2か月後の2003-04-15T00:00:00Z、つまり59日後に終了します。
- 間隔2003-07-15T00:00:00Z/P2Mは2か月後の2003-09-15T00:00:00Z、つまり62日後に終了します。
期間フォーマット（またはそのサブセット）は、期間フォーマットのサブセットをサポートするJava 8 Durationクラスのように、時間間隔とは関係なく広く使用されています。[41] [42]
時間間隔
| <開始>/<終了> |
| <開始>/<期間> |
| <継続時間>/<終了> |
| <所要時間> |
時間間隔とは、2 つの時点の間にある時間のことです。 時間の経過は、期間で表されます (前のセクションで説明したとおり)。 2 つの時点 (開始と終了) は、日付と時刻を組み合わせた表現、または日付のみの表現で表されます。
時間間隔を表現する方法は 4 つあります。
- 開始と終了 (例: "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z")
- 開始と期間 (例: "2007-03-01T13:00:00Z/P1Y2M10DT2H30M")
- 期間と終了 (例: "P1Y2M10DT2H30M/2008-05-11T15:30:00Z")
- 期間のみ（「P1Y2M10DT2H30M」など）と追加のコンテキスト情報
これらのうち、最初の3つは、通常は斜線（より一般的にはスラッシュ「/」と呼ばれる）である間隔指定子で区切られた2つの値を必要とします。ISO 8601-1:2019のセクション3.2.6には、「通信相手の合意により、斜線を二重ハイフン[「--」]に置き換えることができる」と記載されており、以前のバージョンでは「2000--2002」のような表記法が使用されていました。[43]斜線の代わりに二重ハイフンを使用すると、コンピュータのファイル名に含めることができます。[44]一般的なオペレーティングシステムでは、斜線は予約文字であり、ファイル名には使用できません。
<start>/<end> 式では、終了値に要素が欠落している場合、それらはタイム ゾーンを含む開始値と同じであるとみなされます。この標準機能により、時間間隔を簡潔に表現できます。たとえば、開始時間と終了時間を含む 2 時間の会議の日付は、「2007-12-14T13:30/15:30」と表示され、「/15:30」は「/2007-12-14T15:30」(開始と同じ日付) を意味します。また、月次請求期間の開始日と終了日は、「2008-02-15/03-14」と表示され、「/03-14」は「/2008-03-14」(開始と同じ年) を意味します。
時間間隔をより正確に表す必要がある場合は、表現にさらに多くの時間要素を追加できます。「2007-11-13/15」と表記された間隔は、 2007-11-13の任意の時間に開始し、 2007-11-15の任意の時間に終了できますが、「2007-11-13T09:00/15T17:00」には開始時刻と終了時刻が含まれます。すべての開始日と終了日を明示的に含めるには、間隔を「2007-11-13T00:00/16T00:00」と表記します。
繰り返し間隔
| Rn/<間隔> |
| R/<間隔> |
繰り返し間隔は、「4.5 繰り返し時間間隔」の項で指定されます。間隔式の先頭に「R[n]/」を追加することで形成されます。ここで、R は文字自体として使用され、[n] は繰り返し回数に置き換えられます。[n] の値を省略するか、値 -1 を指定すると、繰り返し回数に制限はありません。[n] の値が 0 の場合、間隔は繰り返されません。
間隔で開始が指定されている場合 (上記の形式 1 および 2)、これが繰り返し間隔の開始になります。間隔で終了が指定されているが開始が指定されていない場合 (上記の形式 3)、これが繰り返し間隔の終了になります。たとえば、「2008-03-01T13:00:00Z」から「P1Y2M10DT2H30M」の間隔を 5 回繰り返すには、「R5/2008-03-01T13:00:00Z/P1Y2M10DT2H30M」を使用します。
切り捨てられた表現（非推奨）
ISO 8601:2000 では、日付または時刻の先頭の要素を省略する切り捨てが (合意により) 許可されていました。特に、これにより 2 桁の年や、あいまいな形式である YY-MM-DD および YYMMDD が使用できるようになりました。この規定は ISO 8601:2004 で削除されました。
上記の最初の例と 7 番目の例-では、世紀の先頭が省略されています。その他の形式では、-形式を明確にするために、省略された世紀、年、月、週、時間、分ごとに 1 つの先頭が付けられます。
標準化された拡張機能
ISO 8601-2:2019 は、ISO 8601 の日付と時刻の形式に対する標準化された拡張機能のセットを定義します。
- 拡張日付/時刻形式 (EDTF)
- EDTFはISO 8601のプロファイルの例として挙げられている。その特徴のいくつかは以下の通りである。[9]
- 不確実で近似的な修飾子「?」と「~」、およびそれらの組み合わせ「%」は、日付全体または個々のコンポーネントに適用できます。
- 終了がオープン（無制限）または不明な終了を持つ時間間隔。
- 年単位の指数表記と有効数字表記。
- 季節や四半期などのサブ年のグループを示す特別な「月」値。
- 日付のリストをシリアル化するための構文。
- EDTF 機能については、ISO 8601-2:2019 の「日付と時刻の拡張」セクションで説明されています。
- 繰り返し時間間隔の繰り返しルール
- ISO 8601-2:2019 では、 iCalendarの構文に基づいて繰り返し間隔を制限する形式も定義されています。
使用法
インターネットでは、ワールドワイドウェブコンソーシアム（W3C）がISO 8601に基づくIETF標準を使用して、エラーの可能性とソフトウェアの複雑さを軽減するために、サポートされる日付と時刻の形式を制限する標準のプロファイルを定義しています。この非常にシンプルな仕様は、以下に示すRFC 3339のドラフトに基づいています。[45]
ISO 8601はいくつかの仕様で参照されていますが、ISO 8601のオプションのすべてが常に使用されるわけではありません。たとえば、テレビやデジタルラジオなどのさまざまな電子番組ガイド規格では、時間や期間のポイントを記述するためにいくつかの形式が使用されています。ID3オーディオメタデータ仕様もISO 8601のサブセットを使用しています。 [46] X.690エンコーディング規格の GeneralizedTimeは、ISO 8601の別のサブセットを使用しています。
商業
2006 年現在、ISO 週番号は、米国の主要な商業用パッケージに基本的な形式で表示されています。[要出典]その表示は、特定のブランドよりも、特定のパッケージ、缶詰、または瓶詰め工場に依存していました。この形式は、製造エラーを簡単に追跡できるため、品質保証に特に役立ちます。
RFC
IETF RFC 3339 [47]は、インターネットプロトコルと標準で使用するためのISO 8601のプロファイルを定義しています。これは、西暦以前の期間と日付を明示的に除外しています。週番号や序数などのより複雑な形式は許可されていません。[48]
RFC 3339 は、ISO 8601 では禁止されているゼロタイムゾーンオフセットを「-00:00」として指定できる点で ISO 8601 から逸脱しています。RFC 3339 では、「-00:00」は優先タイムゾーンを示さないという含意を持たせることを意図していますが、準拠している「+00:00」またはゼロ以外のオフセットは、使用されているオフセットが優先されていることを暗示しています。「-00:00」に関するこの規則は、電子メールヘッダーのタイムスタンプにそれを使用する RFC 2822 などの以前の RFC から派生しています。[49] RFC 2822 は、タイムスタンプ形式のどの部分も ISO 8601 に準拠していると主張しておらず、この規則を矛盾なく自由に使用できました。
RFC 3339 を基盤として、IETF はRFC 9557 でインターネット拡張日付/時刻形式 (IXDTF) を導入しました。 [50]この形式は、タイムスタンプの表現を拡張して、関連するタイムゾーン名などの追加情報を含めます。タイムゾーン名を含めることは、夏時間への移行などのイベントを考慮する必要があるアプリケーションにとって特に便利です。さらに、IXDTF は、タイムスタンプにタイムゾーン名を添付するための既存の構文との互換性を維持しており、インターネット上のタイムスタンプ表現に対する標準化された柔軟なアプローチを提供します。例:
1996-12-19T16:39:57-08:00[America/Los_Angeles]
国家標準としての採用
参照
- 天文学上の年号
- 国別の日付と時刻の表現
- 国別の日付形式
- 時計学
- ISO 8601 とWikiversityの日付間の差異の計算
注釈と参考文献
- ^ abc ISO 8601-1:2019/Amd 1:2022、ISO、 2022-10-25
- ^ ab ISO 8601:2004[E] セクション 1 範囲
- ^ ab ISO 8601:2004(E)、ISO、2004-12-01、
附属書 A: ... この概念から、他のすべての日付と時刻の値の表現が論理的に導き出されたため、ISO 2014、ISO 3307、および ISO 4031 は置き換えられました。 ... 序数日付 (ISO 2711) および週番号システム (ISO 2015) による特定の日付の識別は、この国際規格の基本概念に含まれる代替方法でした。そのため、ISO 2015 および ISO 2711 は置き換えられました。
- ^ ISO 8601:2004(E) . ISO . 2004-12-01. p. iv 序文.
- ^ 「TC 154 商業、産業、行政におけるプロセス、データ要素、文書」。技術委員会。ISO。2016年5月25日時点のオリジナルよりアーカイブ。2014年8月16日閲覧。
- ^ 「新しい ISO 8601-1 および ISO 8601-2 の紹介」。ISO /TC 154。2019年 8 月 26 日。
- ^ 「ISO/DIS 8601-1:2016-10-26」(PDF)。米国議会図書館。2017年10月19日時点のオリジナル(PDF)からアーカイブ。
- ^ 「ドイツのドラフト E DIN ISO 8601-1:2017-02 Datenelemente und Austauschformate - Informationsaustausch - Darstellung von Datum und Uhrzeit - Teil 1: Grundlegende Regeln (ISO/DIS 8601-1:2016)」。 DIN-Normanausschuss Informationstechnik und Anwendungen (NIA)。 2017-10-20 のオリジナルからアーカイブ。2017年10月19日に取得。
- ^ ab 「Extended Date/Time Format (EDTF) 仕様」。米国議会図書館。2019-10-08 [2019-02-04、2014、2012]。2020-03-07時点のオリジナルよりアーカイブ。2020-03-07に取得。
- ^ 「Extended Date/Time Format (EDTF) Background」.米国議会図書館. 2019-10-08 [2019-03-01]. 2020-03-07時点のオリジナルよりアーカイブ。 2020-03-07に閲覧。
- ^ 「Extended Date/Time Format (EDTF) 1.0 2012/2014」。ドラフト提出。米国議会図書館。2017年7月15日時点のオリジナルよりアーカイブ。 2017年7月15日閲覧。
- ^ 「ISO/WD 8601-2:2016-02-16」(PDF)。米国議会図書館。2017年10月19日時点のオリジナル(PDF)からアーカイブ。
- ^ 「ISO/DIS 8601-2:2016-10-26」(PDF)。米国議会図書館。2017年10月20日時点のオリジナル(PDF)からアーカイブ。
- ^ 「ドイツのドラフト E DIN ISO 8601-2:2017-02 Datenelemente und Austauschformate - Informationsaustausch - Darstellung von Datum und Uhrzeit - Teil 2: Erweiterungen (ISO/DIS 8601-2:2016)」。 DIN-Normanausschuss Informationstechnik und Anwendungen (NIA)。 2017-10-19 のオリジナルからアーカイブ。2017年10月19日に取得。
- ^ ab ISO: 「ISO 8601 — 日付と時刻の形式」。Wayback Machineで 2013-03-08 にアーカイブ。
- ^ Wolf, Misha; Wicksteed, Charles (1997年9月15日). 「日付と時刻の形式」. W3C . 2021年5月10日時点のオリジナルよりアーカイブ。2021年5月11日閲覧。
- ^ ISO 8601:2004 セクション 2.3.3 基本フォーマット
- ^ ISO 8601 の以前のバージョンでは、関連セクションで「精度」ではなく「精度」という単語が使用されていました(例: 2.3.7 精度を低下させた表現)。これは ISO 8601-1:2019 で修正されました。
- ^ Doggett, LE (1992)。「カレンダー」。PK Seidelmann (編) 著。天文年鑑補足。カリフォルニア州サウサリート: University Science Books。p. 580。ISBN 0-935702-68-72004-04-01 にオリジナルからアーカイブされました。
グレゴリオ暦は現在、民間用の国際標準として使用されています。
- ^ ISO 8601:2004(E)。ISO。 2004 年 12 月 1 日。セクション 4.1.2.1 一般。
- ^ ISO 8601:2004(E) . ISO . 2004-12-01.
3.5 拡張... 情報交換のパートナーの合意により、通常は 4 桁に制限される暦年を識別するコンポーネントを拡張することが許可されます。これにより、完全な表現でサポートされている範囲外の暦年の日付と時刻、つまり年の開始 [0000] より前または年の終了 [9999] より後の日付と時刻を参照できるようになります。
- ^ ISO 8601:2004 セクション 3.4.2、4.1.2.4
- ^ たとえば、規格の付録 B.1.1 を参照してください。
- ^ ISO 8601:2000 の最後で、Perreault, S. (2011 年 8 月) によって使用されています。「DATE」。vCard 形式の仕様。IETF。sec . 4.3.1。doi : 10.17487/RFC6350。RFC 6350。2021年1 月 21 日に取得。 [ ISO.8601.2000]のセクション 5.2.1.3 d)、e)、および f) で指定されている
切り捨てられた表現が許可されます。
ただし、ISO 8601:2004では削除されている。 - ^ Perreault, S. (2011 年 8 月). 「DATE」. vCard フォーマット仕様. IETF . sec. 4.3.1. doi : 10.17487/RFC6350 . RFC 6350. 2016 年 6 月 29 日取得。
[ISO.8601.2000] のセクション 5.2.1.3 d)、e)、および f) で指定されている切り捨て表現が許可されます。
- ^ ISO 8601-1:2019 セクション 5.3.1.3 精度を下げた表現
- ^ ISO 8601-1:2019 セクション 3.1.3.9 小数点
- ^ ISO 8601:2004(E)、ISO、2004-12-01、4.2.2.4
... 小数部は、ISO 31-0 で規定されている小数点記号、つまりカンマ [,] またはピリオド [.] で整数部から除算されるものとする。これらのうち、カンマが推奨される記号である。
- ^ 「ISO 8601 形式」。TechNet。Microsoft Docs。2008年 12 月 3 日。2021 年 10 月 20 日時点のオリジナルよりアーカイブ。2021年 10 月 20 日に取得。
- ^ Markus Kuhn (2020-06-16). 「国際標準の日付と時刻の表記法の概要」。2022年10月5日時点のオリジナルよりアーカイブ。2022年10月5日閲覧。
- ^ 「Communication Guidelines General ACP 121(I)」（PDF）。Combined Communications Electronics Board 。2010年10月。 2018年1月16日時点のオリジナルよりアーカイブ（PDF）。2018年1月15日閲覧。
- ^ McCarthy, Dennis D. ; Seidelmann, Kenneth P. (2009).時間: 地球の自転から原子物理学まで. Weinheim: Wiley-VCH Verlag GmbH & Co. KGaA . p. 10. ISBN 978-3-527-40780-4。
- ^ ISO 8601-1:2019 セクション 3.2.4、ISO 8601:2004 セクション 3.4.2
- ^ RFC 3339 – 不明なローカルオフセット規約
- ^ Newman, Chris (2002年7月). 「未知のローカルオフセット規則」。Klyne, Graham (編) 著。インターネット上の日付と時刻:タイムスタンプ。IETF . sec. 4.3. doi : 10.17487/RFC3339 . RFC 3339 . 2021年2月1日取得。UTC
の時刻はわかっているが、現地時間へのオフセットが不明な場合は、「-00:00」のオフセットで表すことができます。これは、指定された時刻の優先参照点がUTCであることを意味する「Z」または「+00:00」のオフセットとは意味的に異なります。RFC2822 [IMAIL-UPDATE] は、電子メールの同様の規則について説明しています。
- ^ 「3.4.1 表現に使用される文字 - 概要」。データ要素と交換形式 - 情報交換 - 日付と時刻の表現 - パート 1: 基本ルール(PDF) (pdf) 。ISO . 2016-02-16。p. 12。ISO/WD 8601-1。2022-10-05にオリジナルからアーカイブ(PDF)
。ISO/IEC 646 に基づく文字レパートリーを使用する環境では、「ハイフン」と「マイナス」は両方とも「ハイフンマイナス」にマッピングされます。「プラスマイナス」を使用した表現は、交換レパートリーに「プラスマイナス」が含まれている場合にのみ、そのような環境で使用する必要があります。
- ^ ISO 8601:2004(E): データ要素および交換フォーマット - 情報交換 - 日付および時刻の表現。ISO。2004-12-01。4.3.2注: 情報交換のパートナーの合意により、日付および時刻の表現がこの国際
規格で定義されている他の表現と混同される恐れがないアプリケーションでは、文字 [T] を省略できます。
- ^ G. Klyne、C. Newman (2002 年 7 月)。「 インターネット日付/時刻形式」。インターネット上の日付と時刻: タイムスタンプ。第 5.6 節。doi : 10.17487/RFC3339。RFC 3339。注
: ISO 8601 では、日付と時刻を「T」で区切って定義しています。この構文を使用するアプリケーションでは、読みやすさを考慮して、完全な日付と完全な時刻を (たとえば) スペース文字で区切って指定することもできます。
- ^ 「データ要素と交換フォーマット - 情報交換 - 日付と時刻の表現 - パート 1: 基本ルール」(PDF)。米国議会図書館。p. 23。2021-03-12のオリジナルからアーカイブ(PDF) 。2021-07-06に取得。b
) 特定のアプリケーションで必要な場合、最下位のコンポーネントに小数が含まれる場合があります。
- ^ ISO 8601:2004 セクション 4.4.3.3 代替フォーマット、ISO 8601-1:2019 セクション 5.5.2.4 代替フォーマット
- ^ 「Java 8 Class Duration」。Java Platform Standard Edition 8。Oracle。2017年10月14日時点のオリジナルよりアーカイブ。2017年10月7日閲覧。
- ^ 「Amazon Alexa Duration」。Amazon Developer。Amazon.com。2017年10月14日時点のオリジナルよりアーカイブ。2017年10月7日閲覧。
- ^ 「ISO 8601 日付と時刻の表現標準に関する情報」 Cs.tut.fi。2017 年 10 月 14 日時点のオリジナルよりアーカイブ。2012 年 8 月 29 日閲覧。
- ^ 「ISO 8601 - 時代（と日付）に合わせる」 Hydrogold. 2012-01-01. 2014-01-25 時点のオリジナルよりアーカイブ。2013-08-13に取得。
- ^ ロイターの W3C への日付と時刻の形式に関する注意 アーカイブ 2011-08-24ウェイバック マシン
- ^ Nilsson, M. (2000-11-01). 「ID3 タグ バージョン 2.4.0 - メイン構造」. id3.org. pp. §4. 2015-03-09 にオリジナルからアーカイブ。2009-09-27に取得。
- ^ Newman, Chris; Klyne, Graham (2002 年 7 月). インターネット上の日付と時刻: タイムスタンプ. IETF . doi : 10.17487/RFC3339 . RFC 3339. 2015 年 10 月 25 日閲覧。
- ^ Newman, Chris; Klyne, Graham (2002 年 7 月)。「インターネットの日付/時刻形式」。インターネット上の日付と時刻: タイムスタンプ。IETF。p . 8。sec. 5.6。doi : 10.17487/RFC3339。RFC 3339。2015年10 月25日閲覧。
- ^ 「日付と時刻の仕様」。インターネット メッセージ フォーマット。IETF。2001年 4 月。p. 14。sec. 3.3。doi : 10.17487 / RFC2822。RFC 2822 。
- ^ Sharma, Ujjwal; Bormann, Carsten (2024). インターネット上の日付と時刻: 追加情報付きタイムスタンプ。IETF . doi : 10.17487 /RFC9557 . RFC 9557. 2024年5月28日閲覧。
- ^ カナダ国家規格「CAN/CSA-Z234.4-89 (R2007): 全数字の日付と時刻」カナダ規格協議会。1989年12月31日。2018年3月30日時点のオリジナルよりアーカイブ。 2018年3月29日閲覧。
- ^ "ČSN ISO 8601 (979738) Datové prvky a formáty výměny - Výměna informationací - Zobrazení data a času". 2023-04-17 。2023-04-17に取得。
- ^ “DOF - Diario Oficial de la Federación”. 2021年11月10日のオリジナルからアーカイブ。2021年11月10日閲覧。
- ^ ツブラ、アルビン (2020-12-04). 「Główny Urząd Miar」(PDF)。Główny Urząd Miar 。2020年12月4日に取得。
- ^ “SANS 8601:2009 (Ed. 2.00)”. SABS Webstore . 2021年11月24日時点のオリジナルよりアーカイブ。2021年11月24日閲覧。
- ^ 「SS-ISO 8601-1:2022」. SIS Webストア. 2023年10月6日閲覧。
外部リンク
ウィキメディア・コモンズにはISO 8601に関連するメディアがあります。
- ISO 8601:2004 の ISO カタログ エントリ
- ISO 8601-1:2019のプレビュー
- ISO 8601-2:2019のプレビュー
- ISO 8601-1 (ISO/TC 154 N) の 2016 プロトタイプ (アーカイブ)
- ISO 8601-2 (ISO/TC 154 N) の 2016 年プロトタイプ (アーカイブ)
- 国際日付形式 (ISO) を使用する – 品質の高い Web のヒント World Wide Web Consortium (W3C)
- ケンブリッジ大学の Markus Kuhn 博士による ISO 8601 の概要
- Wayback Machineの ISO による 8601 の要約(2011-06-14 アーカイブ)
- ユトレヒト大学のRH van Gent氏のウェブサイトからのISO 8601カレンダーの数学
- W3C「注意」: 日付と時刻の形式、ISO 8601:1988 のプロファイルを指定
- RFC 3339 と ISO 8601 — 2 つの標準の違いを示すベン図。
実装の概要
- ISO 8601 の世界規模での導入 (1998)