Loading article…
ISO 8601は、日付と時刻に関連するデータの世界的な交換と通信を対象とする国際規格です。国際標準化機構(ISO) によって維持されており、1988 年に初版が発行され、1991 年、2000 年、2004 年、2019 年に更新され、2022 年に改訂版が発行されています。[ 1 ]この規格は、特に数値の日付と時刻の表記規則が異なる国間でデータが転送される際に、数値の日付と時刻の誤解を避けるために、世界的な通信でカレンダーの日付と時刻を表す明確で曖昧さのない方法を提供します。
ISO 8601 は、グレゴリオ暦 (予見グレゴリオ暦を含む) による日付、 24 時間制に基づく時刻(オプションのUTC オフセット、時間間隔、およびそれらの組み合わせを含む) の表現と形式に適用されます。 [ 2 ]この規格では、表現される日付/時刻のどの要素にも特定の意味を割り当てていません。どの要素の意味も、その使用のコンテキストに依存します。表現される日付と時刻には、規格内で数値的な意味が指定されていない単語 (したがって、中国暦の年の名前は除外されます) や、コンピュータ文字を使用しない単語(画像や音声は除外されます) を使用することはできません。[ 2 ]
ISO 8601 交換規格に準拠した表現では、日付と時刻は、最も長い時間単位 (通常は年) が左に配置され、それより小さい時間単位が前の時間単位の右側に順次配置されるように配置されます。表現は、アラビア数字[ 3 ]と、規格内で特定の意味が割り当てられている特定のコンピュータ文字 (「‐」、「:」、「T」、「W」、「Z」など) の組み合わせで記述する必要があります。つまり、この規格内の交換表現では、「1 月」、「木曜日」、「元旦」などの一般的な日付 (または日付の一部) の記述は許可されていません。
ISO 8601規格の初版は、1988年6月にISO 8601:1988として発行されました。これは、日付と時刻の表記に関するさまざまな側面について、多くの古いISO規格を統合し、置き換えたものです[ 4 ] 。
この最初の統一版は、 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 およびその前身のすべての版と部分は、 [ 10 ] によって作成され、 ISO 技術委員会TC 154の直接の責任下にあります。[ 11 ]
2019 年 2 月に発行された[ 3 ]規格の第 4 版である ISO 8601-1:2019 は、以前の ISO 8601:2004 規格[ 12 ] [ 1 ]の内容をわずかに更新したものですが、現在は 2 つのパートのうちの最初のものです。もう 1 つのパートである ISO 8601-2:2019 は完全に新しいものです。不確実性や拡張日付/時刻フォーマット (EDTF)の一部など、さまざまな拡張機能を定義しています。[ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ]
ISO 8601-1の改訂版が2022年10月に発行され、軽微な技術的明確化と定義の曖昧さの解消が試みられた。しかし、最も重要な変更点は、暦日の終わりの瞬間を表すために「24:00:00」形式が再導入されたことである。
ISO 8601-2の改訂版が2025年1月に発行されました。
この規格はグレゴリオ暦を使用しており、グレゴリオ暦は「市民使用のための国際標準として機能する」[ 23 ] 。
ISO 8601では、1582年10月15日のグレゴリオ暦導入以降の日付が認められています。それ以前の日付（グレゴリオ暦導入以前）については、関係者の明示的な合意により、グレゴリオ暦導入以前の日付（プレレプティック・グレゴリオ暦）を使用することができます。ただし、このようなプレレプティック・グレゴリオ暦の日付をユリウス暦の日付と整合させるために調整することはできません。
ISO 8601 では、 2000 年問題を 回避するために、少なくとも 4 桁の年 [YYYY] を規定しています。したがって、0000 から 9999 までの年を表し、0000 年は紀元前 1 年、その他は西暦 1 年で、天文学的な年番号付けに似ています。ただし、1583 年 (グレゴリオ暦の導入後の最初の完全な年) より前の年は、この規格で自動的に許可されるわけではありません。代わりに、この規格では、「[0000] から [1582] の範囲の値は、情報交換のパートナー間の相互合意によってのみ使用される」と述べています。[ 24 ]
0000 より前または 9999 より後の年を表すために、この規格では、送信者と受信者の事前の合意がある場合に限り、年表現の拡張も許可されています。[ 25 ]拡張された年表現 [±YYYYY] は、4 桁の最小値を超えて合意された数の追加の年桁を持つ必要があり、より一般的な AD/BC (または CE/BCE) 表記の代わりに + または - 記号[ 26 ]を接頭辞として付ける必要があります。慣例として、紀元前 1 年は +0000、紀元前 2 年は -0001 と表記され、以下同様です。[ 27 ]
カレンダー日付の表現は、隣のボックスに示されている形式です。[YYYY] は 0000 から 9999 までの 4 桁の年を表します。[MM] は 01 から 12 までの 2 桁の月の月を表します。[DD] は 01 から 31 までの 2 桁の日を表します。たとえば、「1981 年 4 月 5 日」は、拡張形式では「1981-04-05」[ 19 ] 、基本形式では「19810405」と表現できます。
また、この規格では、カレンダーの日付を精度を下げて記述することも許可されています。たとえば、「1981-04」と記述すると、「1981 年 4 月」という意味になります。単に「1981」と記述するとその年を指し、「198」と記述すると1980 年から 1989 年までの10 年間を指し、「19」と記述すると 1900 年から 1999 年までの世紀を指します。この規格では、完全なカレンダーの日付表現として「YYYY-MM-DD」と YYYYMMDD の両方の形式が許可されていますが、日付 [DD] が省略されている場合は、YYYY-MM形式のみが許可されます。YYYYMM 形式の日付を許可しないことで、この規格は切り捨て表現[ 30 ] [ 4 ] YYMMDD (今でもよく使われています)との混同を回避しています。 2000年版では「--04-05」という省略形を「4月5日」という意味で記述することもできたが[ 28 ]、2004年版では月がある場合に年を省略することはできない。
例：
週の日付表示は、隣のボックスに示す形式です。[YYYY] はISO 週番号の年を表し、これは従来のグレゴリオ暦の年とは若干異なります (下記参照)。[Www] は、W01 から W53 までの文字Wが接頭辞として付いた週番号です。[D] は、月曜日から日曜日まで 1 から 7 までの曜日番号です。
第1週については、相互に同等かつ互換性のある複数の記述が存在する。
したがって、1月1日が月曜日、火曜日、水曜日、または木曜日の場合は、第1週となります。1月1日が金曜日、土曜日、または日曜日の場合は、前年の第52週または第53週となります（第0週はありません）。12月28日は常にその年の最終週となります。
週番号は木曜日の数を数えることで表すことができます。例えば、第12週は1年の12回目の木曜日を含みます。
ISO週番号付け年は、第1週の最初の日（月曜日）から始まり、新しいISO年の前の日曜日で終わります（したがって、重複や空白はありません）。52週または53週で構成されます。ある年の最初のISO週には、実際に終了するグレゴリオ暦年に含まれる日が最大3日ある場合があります。3日ある場合は、月曜日、火曜日、水曜日です。同様に、ある年の最後のISO週には、実際に開始するグレゴリオ暦年に含まれる日が最大3日ある場合があります。3日ある場合は、金曜日、土曜日、日曜日です。各ISO週の木曜日は、常にISO週番号付け年で示されるグレゴリオ暦年に属します。
例：
序数日付とは、年初からの経過日数を日数で表す形式です。「YYYY-DDD」（またはYYYYDDD）の形式で表され、[YYYY]は年、[DDD]は「その年の日数」を表し、001から365（閏年は366 ）までの値をとります。例えば、「1981-04-05」は「1981-095」と同じです。
このシンプルな形式は、週と月の定義の恣意性が、例えば異なるカレンダーの日付を比較する場合など、助けになるよりもむしろ妨げになるような場合に好ましい。この形式は、日付システムを必要とするが、完全なカレンダー計算ソフトウェアを含めることが大きな面倒となるようなシンプルなハードウェア システムで使用される。このシステムは「ユリウス日」と呼ばれることもあるが、これは天文学的なユリウス日と混同される可能性がある。ユリウス日は、紀元前 4713 年 1 月 1日のグリニッジ標準時正午 (または、0000 年をグレゴリオ標準時とする ISO 日付-4713-11-24の正午)から始まる日数を順に数えるものである。
ISO 8601は24時間 制を採用しています。ISO 8601-1:2019以降、基本形式はT[hh][mm][ss]、拡張形式はT[hh]:[mm]:[ss]となっています。以前のバージョンでは、どちらの形式もT（時刻を表す）が省略されていました。
そのため、時刻は基本形式では「T134730」、拡張形式では「T13:47:30」のように表示されることがあります。ISO 8601-1:2019では、拡張形式では「13:47:30」のようにTを省略できますが、基本形式では日付表現との混同の恐れがない場合にのみTを省略できます。
基本時間形式または拡張時間形式から秒、または分と秒を省略すると、より簡潔になりますが精度が低下します。結果として得られる精度が低下した時間形式は次のとおりです。[ 31 ]
ISO 8601-1:2019/Amd 1:2022 の時点では、「00:00:00」は暦日の開始時点に対応する真夜中を指すために使用でき、「24:00:00」は暦日の終了時点に対応する真夜中を指すために使用できます。 [ 30 ]最初に発行されたISO 8601-1:2019 では、以前のバージョンの規格で許可されていた「24:00:00」を日の終わりを表す表現として削除しました。
これらの表現のいずれかに含まれる最小の時刻要素に小数点を追加することができます。時刻要素とその小数点の間の区切り文字として、ベースライン上のコンマまたはドットのいずれかの小数点記号が使用されます。（ ISO 8601:1-2019 に基づくISO 80000-1に従い、[ 32 ]国際規格内を除き優先順位は規定されていませんが、ISO 8601:2004に従ってコンマが推奨されています。 [ 33 ]）たとえば、「14 時間 30 分 30 分」を表すには、秒の数字を含めず、「14:30,5」、「T1430,5」、「14:30.5」、または「T1430.5」と表現します。
小数部分の桁数に制限はありません。ただし、小数部分の桁数は通信当事者間で合意する必要があります。たとえば、Microsoft SQL Server では、 DATETIME の小数部分の精度は 3 であり、つまり「yyyy-mm-ddThh:mm:ss[.mmm]」となります。[ 34 ]
ISO 8601におけるタイムゾーン は、現地時間（場所が指定されていない）、UTC、またはUTCからのオフセットとして表されます。
時刻表現にUTCとの関連情報が指定されていない場合、時刻は現地時間であるとみなされます。同じタイムゾーン内で通信する場合は現地時間とみなしても問題ありませんが、異なるタイムゾーン間で通信する場合は曖昧さが生じます。同じ地理的タイムゾーン内であっても、その地域で夏時間が実施されている場合は、現地時間が曖昧になることがあります。通常は、標準規格の表記法を用いてタイムゾーン（ゾーン指定子）を示すことが望ましいです。
時刻がUTCの場合は、時刻の直後にスペースを入れずにZを追加します。ZはUTCオフセット0を表すゾーン指定子です。したがって、「09:30 UTC」は「09:30Z」または「T0930Z」と表記されます。「14:45:15 UTC」は「14:45:15Z」または「T144515Z」となります。
ISO 8601 時刻表現のZ接尾辞は 、同じ文字がズールー時間帯を指定するために使用されているため、「ズールー時間」または「ズールー子午線」と呼ばれることがあります。[ 35 ]しかし、軍事時間帯のリストを定義する ACP 121 規格では UTC については言及されておらず、「ズールー時間」は、かつて国際的な民間時間標準として使用されていたグリニッジ標準時[ 36 ]から派生しています。GMTはもはや科学界で厳密に定義されておらず、文脈に応じて UTC またはUT1のいずれかを指すことがあります。[ 37 ]
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」となります。
その他のUTCオフセットについては、 「UTCオフセット一覧」を参照してください。
ゼロ値の時間オフセットをマイナス記号で表記することは許可されていません。「− 00:00」、「− 0000」、「− 00」のように表記することはできません。符号の使用を規定するセクションでは、正またはゼロの値にはプラス記号を、負の値にはマイナス記号を使用する必要があると規定されています。プラスマイナス記号（±）が使用可能な場合は、それを使用することもできます。[ 38 ]
この規則とは対照的に、ISO 8601のプロファイルである RFC 3339 では、「 − 00」を「+00」と同じ表記で使用しても、意味合いが異なり、未知のUTC オフセットとして使用されることを認めている。[ 39 ] [ 40 ]
負のオフセットを表すには、ISO 8601 ではマイナス記号( − ) を使用することを規定しています。交換文字セットが限定されていてマイナス記号文字がない場合は、ハイフンマイナス( - )を使用する必要があります。 [ 41 ] 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」、および有効な時刻表現を連結することによって表すことができます。たとえば、「2007-04-05T14:30」です。ISO 8601:2004 では、 「200704051430」のように相互合意により「T」 文字を省略することが許可されていましたが、[ 42 ] ISO 8601-1:2019 ではこの規定が削除されました。日付と時刻の部分をスペースなどの他の文字で区切ることは ISO 8601 では許可されていませんが、そのプロファイル RFC 3339 では許可されています。 [ 43 ]
タイムゾーン指定子が必要な場合は、日付と時刻の後に記述します。例えば、「2007-04-05T14:30Z」または「2007-04-05T12:30-02:00」のように記述します。
基本形式または拡張形式のいずれも使用できますが、日付と時刻は同じ形式を使用する必要があります。日付の表現は、カレンダー形式、週形式、または序数形式のいずれかであり、完全な表現を使用する必要があります。時刻は、指定された精度低減形式で表現できます。
期間は時間間隔内の経過時間量を定義するもので、横に示されているように 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は日付と時刻の各要素の指定子であり、置き換えられません。[ 44 ]
例えば、「P3Y6M4DT12H30M5S」は「3年6ヶ月4日12時間30分5秒」という期間を表します。
日付と時刻の要素（指定子を含む）は、値がゼロの場合は省略できます。また、精度を落とすために下位の要素も省略できます。たとえば、「P23DT23H」と「P4Y」はどちらも有効な期間表現です。ただし、少なくとも1つの要素が存在する必要があるため、「P」は0秒の期間を表す有効な表現ではありません。一方、「PT0S」または「P0D」はどちらも有効で、同じ期間を表します。
曖昧さを解消するために、「P1M」は1か月、「PT1M」は1分を表します（時間値の前に時間指定子Tが付いていることに注意してください）。使用される最小値には、半年を表す「P0.5Y」のように小数点[ 45 ]が付く場合もあります。この小数は、「P0,5Y」または「P0.5Y」のように、コンマまたはピリオドで指定できます。標準では、以下に述べる場合を除き、期間表現における日付と時刻の値が「繰り越しポイント」を超えることを禁止していません。したがって、同じ期間を表すために「PT36H」と「P1DT12H」の両方を使用できます。ただし、夏時間への切り替えまたは夏時間からの切り替え時には、「PT36H」と「P1DT12H」は同じではないことに注意してください。
あるいは、通信当事者間の合意により、日付と時刻の組み合わせ表現に基づく期間の形式を、基本形式 PYYYYMMDDThhmmss または拡張形式P[YYYY]-[MM]-[DD]T[hh]:[mm]:[ss] のいずれかで使用することができます。たとえば、上記で示した最初の期間は"P0003-06-04T12:30:05"となります。ただし、個々の日付と時刻の値は、その剰余値を超えることはできません(たとえば、月の値として 13 や時間の値として 25 は許容されません)。[ 46 ]
この規格では、期間を時間間隔の一部として記述しており、時間間隔については次のセクションで説明します。期間形式単独では、暦年および暦月の総日数に関して曖昧です。閏秒があるため、暦日の秒数も曖昧です。たとえば、「P1M」単独では、28日、29日、30日、または31日になる可能性があります。時間間隔内で使用される場合は、曖昧さはありません。例として、2暦月を表す「P2M」の期間を使用します。
期間形式（またはそのサブセット）は、Java 8 Duration クラスが期間形式のサブセットをサポートするように、時間間隔とは無関係に広く使用されています。[ 47 ] [ 48 ]
時間間隔とは、2つの時点間の時間間隔のことです。この時間間隔は、期間（前述のセクションで説明したとおり）で表されます。2つの時点（開始と終了）は、日付と時刻を組み合わせた形式、または日付のみの形式で表されます。
時間間隔を表す方法は4つあります。
これらのうち、最初の 3 つは、通常はスラッシュ「/」である間隔指定子で区切られた 2 つの値を必要とします。 ISO 8601-1:2019 のセクション 3.2.6 には、「通信相手間の合意により、スラッシュを二重ハイフン ["--"] に置き換えることができる」と記載されており、以前のバージョンでは「2000--2002」のような表記が使用されていました。[ 49 ]スラッシュの代わりに二重ハイフンを使用すると、コンピュータのファイル名に含めることができます。[ 50 ]一般的なオペレーティングシステムでは、スラッシュは予約文字であり、ファイル名には使用できません。
<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」と表現します。
繰り返し間隔は、「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番目の例では、-世紀の先頭文字が省略されています。その他の形式では、-省略された世紀、年、月、週、時、分ごとに、形式を明確にするために必要に応じて先頭文字が付けられます。
ISO 8601-2:2019は、ISO 8601の日付および時刻フォーマット に対する一連の標準化された拡張機能を定義しています。
EDTFは、ISO 8601のプロファイルの例として パート2で示されています。EDTFには3つのレベルがあり、レベル0はパート1のサブセットで、RFC 3339と同様に拡張月日表記（CCYY-MM-DD）に限定されており、レベル1とレベル2はそれを基盤としています。
EDTFは主に書誌学および歴史学のニーズに合わせて設計されています。その特徴の一部は次のとおりです。[ 13 ]
EDTF の機能は ISO 8601-2:2019 の「日付と時刻の拡張」のセクションで説明されており 、プロファイル自体は附属書 A に記載されています。これは、米国議会図書館が先駆けて作成した以前の仕様とほぼ同じです。[ 13 ]
GNU CoreUtilsの date コマンドには、他の書式設定パターンに加えて、次の--iso-8601オプションがあります[ 52 ] :
$ date --iso-8601 = ns 2025-02-16T12:03:17,646296349+01:00$ date -u --rfc-3339 = ns 2025-02-16 10:58:44.966864492+00:00$ date -u + "%Y-%m-%dT%H:%M:%S.%6NZ" 2025-02-16T10:58:44.965071Zインターネットでは、World Wide Web Consortium (W3C) がISO 8601 に基づくIETF標準を使用して、サポートされる日付と時刻の形式を制限し、エラーの可能性とソフトウェアの複雑さを軽減する標準のプロファイルを定義しています。非常にシンプルな仕様は、後述するRFC 3339 のドラフトに基づいています。 [ 53 ]
ISO 8601 はいくつかの仕様で参照されていますが、ISO 8601 のオプションの全範囲が 常に使用されるわけではありません。たとえば、テレビ、デジタルラジオなどのさまざまな電子番組ガイド規格では、時点と期間を記述するためにいくつかの形式が使用されています。ID3オーディオメタデータ仕様も、ISO 8601のサブセットを使用しています。 [ 54 ] X.690エンコーディング規格のGeneralizedTimeは、 ISO 8601 の別のサブセットを使用しています。
2006年現在、ISO週日付は、米国における主要ブランドの市販パッケージに基本形式で表示されている。その表示方法は、特定のブランドというよりも、包装、缶詰、または瓶詰め工場によって異なっていた。この形式は、製造上のエラーを容易に追跡できるため、品質保証に特に役立つ。
IETF RFC 3339 [ 55 ]は、インターネット プロトコルおよび標準 で使用するための ISO 8601のプロファイルを定義しています。これは、西暦以前の期間と日付を明示的に除外しています。週番号や序数日などのより複雑な形式は許可されていません。[ 56 ]
RFC 3339 は、ISO 8601 では禁止されているゼロのタイムゾーンオフセットを "-00:00" として指定することを許可している点で ISO 8601 と異なっています。RFC 3339は "-00:00" が優先タイムゾーンを明示していないことを意味しているのに対し、準拠している "+00:00" またはゼロ以外のオフセットは、使用されているオフセットが優先されていることを意味しています。この "-00:00" に関する慣習は、電子メールヘッダーのタイムスタンプにこれを使用している RFC 2822 など、以前の RFC から派生したものです。[ 57 ] RFC 2822 は、タイムスタンプ フォーマットのどの部分も ISO 8601 に準拠していると主張していなかった ため、矛盾なくこの慣習を使用することができました。
RFC 3339 の基盤の上に、IETF はRFC 9557 でインターネット拡張日付/時刻フォーマット (IXDTF) を導入しました。[ 58 ]このフォーマットは、タイムスタンプ表現を拡張し、関連付けられたタイムゾーン名などの追加情報を含めます。タイムゾーン名を含めることは、夏時間移行などのイベントを考慮する必要があるアプリケーションにとって特に便利です。さらに、IXDTF はタイムスタンプにタイムゾーン名を付加するための既存の構文との互換性を維持し、インターネット上のタイムスタンプ表現に対する標準化された柔軟なアプローチを提供します。例:
1996-12-19T16:39:57-08:00[America/Los_Angeles]
附属書
A: ... この概念から、他のすべての日付と時刻の値の表現が論理的に導き出されました。したがって、ISO
2014、ISO
3307、および ISO 4031 は廃止されました。 ... 序数日付 (ISO
2711) および週番号システム (ISO 2015) による
特定の日付の識別は、
この国際規格の基本概念にも包含できる代替方法でした。したがって、ISO
2015 および ISO
2711 は現在廃止されています。
{{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク){{cite web}}: CS1 maint: 数値名: 著者リスト (リンク)グレゴリオ暦は現在、市民生活における国際標準として使用されています。
3.5 拡張 ... 情報交換のパートナー間の相互合意により、通常は 4 桁に制限されている暦年を識別するコンポーネントを拡張することが許可されます。これにより、完全な表現でサポートされている範囲外の暦年の日付と時刻、つまり年の開始前 [0000] または年末後 [9999] を参照できるようになります。
[ISO.8601.2000]、セクション 5.2.1.3 d)、e)、f) で指定されている切り捨て表現が許可されています。
... 小数部分は、ISO 31-0 で指定されている小数記号、すなわちコンマ [,] またはピリオド [.] で整数部分から除算する。これらのうち、コンマが好ましい記号である。
時刻が既知であるが、ローカル時刻へのオフセットが不明な場合は、「-00:00」のオフセットで表すことができます。これは、「Z」または「+00:00」のオフセットとは意味的に異なります。これらのオフセットは、指定された時刻の優先参照点がUTCであることを意味します。RFC2822 [IMAIL-UPDATE] は、電子メールに関する同様の慣例について説明しています。
ISO/IEC 646 に基づく文字レパートリーを使用する環境では、「ハイフン」と「マイナス」は両方とも「ハイフンマイナス」にマッピングされます。「プラスマイナス」を使用した表現は、交換レパートリーに「プラスマイナス」が含まれている場合にのみ、そのような環境で使用できます。
{{citation}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)情報交換のパートナー間の相互合意により、日付及び時刻の表現がこの国際規格で定義されている他の表現と混同されるリスクがないアプリケーションでは、文字 [T] を省略することができる。
、日付と時刻を「T」で区切ると定義されています。この構文を使用するアプリケーションは、読みやすさのために、完全な日付と完全な時刻を (たとえば) スペース文字で区切って指定することを選択できます。
4.4.3.2 指定子を含むフォーマット。[...] コンポーネントの最大桁数は、情報交換のパートナー間で合意する必要がある。[...]
) 特定のアプリケーションで必要な場合は、最下位のコンポーネントに小数が含まれる場合があります。