表記法

[45] ISO 8601 では地の文と日時表現や日時書式表現を区別するために、 表現 (representation) を「[」と「]」で括っています。この括弧は仕様書の表現上のもので、 表現の一部ではないとされています。 >>7 Introduction

[244] 実際 ISO 8601 以外でこの表記法はあまり見かけません。

代替形式

[107] 情報交換の当事者間の合意により、代替形式 (alternative format) を用いることもできます。 これは日時の表現の前に P を付けたものです。 >>7 4.4.3.3

• 暦日付 PYYYY‐MM‐DD
• 通日日付 PYYYY‐DDD
• 地方時 PThh:mm:dd
• 暦日付の日時 PYYYY‐MM‐DDThh:mm:dd
• 通日日付の日時 PYYYY‐DDDThh:mm:dd

[108] ここに示したものの他に、基本書式、精度を削減した表現、小数付き表現、展開表現も認められているようです。

[109] ただしこれらは日付としてではなく、時間長として扱われるため、値域が違っています。 年、月、日は 0 から始まります。また 12月、30日、24時、60分、60秒は認められないようです。 >>7 4.4.3.3

派生

[242] TM_PeriodDuration は ISO 8601の時間長形式を使ったデータ型です。 構文を制限し、グレゴリオ暦と UTC 以外にも拡張しています。

開始と終了による表現

[111] 日時の表現を、開始と終了で2つ並べて、/ で区切ったものです。

[112] すべて基本書式、またはすべて拡張書式で構成されなければなりません >>7 4.4.4.1, >>7 4.4.4.5, >>7 4.4.5。

[113] 両者の前後関係は明記されていませんが、開始と終了ですから、前者が後者以下でなければならないものと思われます。

[121] 終了側の上位側が省略されていれば、開始側と同じ値とみなされます >>7 4.4.5。

[120] 開始側にUTC指示子か時差が含まれていて、終了側に含まれていなければ、 開始側の時間帯が終了側にも適用されます >>7 4.4.5。

[123] 精度を削減する時に前後で精度が一致していなければならないという規定はありませんから、 1098-01-05/1993-03-05T00:12:44 のような表現も良いことになります。

[308] RKMSの時間範囲形式は、不明を表すために開始と終了の一方を省略可能とした拡張でした。

[309] Date Ranges (Dublin Core) は、 W3C-DTF に限定しつつ、開始と終了の一方を省略可能とした拡張でした。

時間長と文脈による表現

[114] 時間長の表現によって、時間間隔の表現とするものです >>7 4.4.4.2, >>7 4.4.4.5, >>7 4.4.5。

開始と時間長による表現

[115] 開始の日時の表現と時間長の表現を並べて、 / で区切ったものです。

[116] すべて基本書式、またはすべて拡張書式で構成されなければなりません >>7 4.4.4.3, >>7 4.4.4.5, >>7 4.4.5。

時間長と終了による表現

[117] 時間長と終了の日時の表現を並べて、 / で区切ったものです。

[118] すべて基本書式、またはすべて拡張書式で構成されなければなりません >>7 4.4.4.4, >>7 4.4.4.5, >>7 4.4.5。

ハイフンとマイナス

[61] マイナスは、日時書式表現の ± に相当する日時表現の部分で使って、 負数を表します。

[62] ハイフンは、年、月、週、日の間の区切りとして使います >>7 3.4.4。

[49] ハイフンやマイナスは、 ISO/IEC 646 を元にした文字レパートリにあっては、 HYPHEN-MINUS を用います。 >>7 3.4.1

小数点

[77] 小数点は時、分、秒の整数部と小数部を分けるために使います。 値が1に満たない時は整数部を 0 や 00 にしなければなりません。 小数点がある時は小数部は1桁以上必要です。 >>7 4.2.2.4, >>7 4.4.3.2

[78] 小数点は , または . を用いることができます。 , がより好ましい (preferred) とされています。 >>7 4.2.2.4, >>7 4.4.3.2

[79] ISO 8601 の日時書式表現や例示の日時表現はすべて , に統一されています。

[80] しかし XML Schemaの日付形式やHTMLの日付形式など主要なプロファイルはすべて . を採用しています。

[139] JIS X 0301 によって拡張された元号による日付の表現では、 ピリオド >>27 5.1.3 を用いています。これは , ではなく、 . でなければなりません。

斜線

[64] / は、time interval や recurring time interval の区切りに使います >>7 3.4.4, >>7 4.4.2 a)。

[98] 応用分野によっては、 / のかわりに二重ハイフンを使うことがあります >>7 4.4.2 NOTE。

主要プロファイルの比較

[25] 主要なプロファイルの違いは次のようになっています。

プロファイルや変種の例

[9] RFC 3339の日付形式は、特定の日時を表す部分集合で、 新しい IETF の技術ではこれを採用することが推奨されています。

[10] XML Schema の仕様書第2部ではいろいろな基本的なデータ型を規定していますが、 その中には RFC 3339 の日付形式に極めてよく似たものを含め、 いくつかの日付や時刻や時間の表現のための形式が定義されています。

[23] HTMLの日付形式のいくつかは、 ISO 8601 をもとに定義されています。

[24] JavaScriptの日付形式には、 ISO 8601の日付形式のプロファイルが含まれています。

[11] W3C Member Submission Note である Date and Time Formats は、 RFC 3339の日付形式を同じものや、それよりも精度が低いもの (時刻を省略したものなど) など数種類の形式 (通称 W3C-DTF) を提案しています。 HTML 4 などが採用していますが、 XML Schema データ型の登場により現在では時代遅れであると考えられています。

[4] RFC 2326の時刻形式の1つ、 npt-range は、 ISO 8601 に従った書式で、演奏時間範囲を指定するのに使われます。

[5] PICSの日付形式は2種類あり、そのうちの新しい方は ISO 8601 に基づく書式です。 XML Schema のデータ型のものと似ていますが、 微妙に異なります。

[14] XLIFF 1.1 Specification (2006-07-08 02:30:08 +09:00 版) http://www.oasis-open.org/committees/xliff/documents/cs-xliff-core-1.1-20031031.htm#date

[22] XLIFF 1.2 Specification (2008-02-05 00:30:42 +09:00 版) http://docs.oasis-open.org/xliff/v1.2/os/xliff-core.html#date

[15] Global Information Management eXchange Metrics Volume 1.0 Specification (2007-02-24 17:44:10 +09:00 版) http://www.lisa.org/standards/gmx/GMX-V.html#Attr_date

>>14 の関連規格だけど日付形式は違う (名無しさん)

[16] TMX Specification (2007-02-24 17:51:20 +09:00 版) http://www.lisa.org/standards/tmx/tmx.html#changedate (名無しさん)

[17] TMX Specification (2007-02-24 17:51:20 +09:00 版) http://www.lisa.org/standards/tmx/tmx.html#creationdate (名無しさん)

[18] TMX Specification (2007-02-24 17:51:20 +09:00 版) http://www.lisa.org/standards/tmx/tmx.html#lastusagedate (名無しさん)

[19] XML Text Memory Namespace 1.0 Specification (2007-02-24 17:56:51 +09:00 版) http://www.lisa.org/standards/xmltm/xml-tm.html#Attr_date (名無しさん)

[20] TermBase eXchange Link (TBX Link) Specification (2007-02-24 18:05:26 +09:00 版) http://www.lisa.org/standards/tbxlink/tbxlink.html#Attr_date

• HTMLの時間形式
• xs:duration

[12] PICSの日付形式は2種類あり、そのうちの古い方は ISO 8601 に基づいた書式であることを意図していましたが、 日付の部分の区切子に誤って HYPHEN-MINUS ではなく FULL STOP を使っていました。 (新しい方の書式では修正されています。)

[13] ISO 8601 の日本版規格である JIS X 0301 (>>39) は、 ISO 8601 に加えて元号を使った和暦の年号を表現するための書式を規定しています。

[21] HTMLの日付形式は実質的に ISO 8601 のプロファイルですが、 ISO 8601 を引用せずに定義されています。 HTML は閏秒に対応していないなどの違いもあります。

[186] OGPの日時形式も、 ISO 8601 を基にしています。

[191] AWS は ISO 8601 形式と称して、 YYYYMMDDThhmmssZ のような記号を使わない形式を用いています >>190。

[195] clock (RTSP)

[196] NPT

[187] XMPPの日時形式も、 ISO 8601 から派生したものです。

その他の応用

[243] ISO 19103の日時形式は、 Date, Time, DateTime など ISO 8601の日時形式を採用したデータ型です。 ISO 19108 など ISO 19100シリーズで使われています。

[269] DSSSL の JIS X 4153:1998 8.5.11 は、 「ISO 8601形式の日付又は時刻」 を扱っていました。

[270] ISO 12083: JIS X 0804-1996 p.115 DATE 要素では、 ISO 8601:1988の方式, mm-dd-yy, mm/dd/yy, dd-mm-yy, 月日年 のいずれかの形式を使えるものとし、 他の形式にも拡張できるとしていました。

[271] DC の Date は ISO 8601 のプロファイルを推奨していました。 JIS 版は JIS X 0301 のプロファイルを推奨していました。 その具象構文の一種である RSS 1.0 の dc:date は、 W3C-DTF とすることを求めていました。 dc:date

[310] RFC 767 - Structured format for transmission of multi-media documents, 2021-02-14T20:19:32.000Z, 2021-03-10T06:31:38.981Z https://tools.ietf.org/html/rfc767#page-7

[313] STONの日時形式

[317] 「ISO style」が何を意味するか明らかではありませんが、 ISO 8601 のことだとすると、 +TZ.TZ は構文が微妙に違っています。

[316] こちらの 「ISO style」 は ISO 8601 の形式。

米国

[275] 米国連邦政府の情報処理用標準規格 FIPS 4 (Federal Information Processing Standard 4) Calendar Date は、 1968-11-01に制定され、 1970-01-01に施行されました。 (施行日以前でも当事者間の合意により実施可能とされました。) >>274

[276] 次のように定めていました。 >>274

• [277] Calendar Date: グレゴリオ暦の Year, Month, Day の6桁
  • [279] Month: 01 (January) - 12 (December)
  • [280] Day: 01 - 31
• [281] Ordinal Day 表現: グレゴリオ暦の Year, Ordinal Day
  • [282] Ordinal Day (Ordinal Number): 001 (January 1) - 365
• [283] Year は2桁。 十年紀内しか使わないなら1桁、 世紀を超えて使うなら4桁としても良い。
• [284] Year, Month, Day, Ordinal Day は単体で使っても、組み合わせて使っても良い。 組み合わせるときは大エンディアンとする。

[287] ANSI X3.30-1971 は、 西暦1971年に制定されました。

[288] ANSI X3.30-1985 は、 1985-07-30に制定されました。 ANSI X3.30-1971 を置き換える改訂版でした。 >>285

[289] ANSI X 3.30-1985 は実質的に FIPS PUB 4 と同内容でしたが、 規定はおおむね FIPS より洗練されていました。 次のように定めていました。 >>285

• [290] calendar date: year, month of year, day of month をつなげたもの。
  • [295] Month: 01 - 12
  • [296] Day: 01 - 31
• [292] ordinal date: year, day of year をつなげたもの。 グレゴリオ暦の Year, Ordinal Day
  • [297] day of year: 001 (January 1) - 365
• [278] year は4桁。
  • [293] 応用依存で、上位2桁の century, 下位2桁の year of century のうち、 year of century を使っても良い。
  • [294] 応用依存で、上位2桁の century, 上から3桁目の decade, 下位1桁の year of decade のうち、 year of decade を使っても良い。
• [298] year, month of year, day of month, day of year は単体で使っても、組み合わせて使っても良い。 組み合わせるときは大エンディアンとする。

[286] FIPS PUB 4-1 は、 1988-01-27に制定されました。 FIPS PUB 4 を置き換える改訂版でした。 ANSI X3.30-1985 をそのまま採用したものでした。 >>285

[306] FIPS PUB 4-1 の1991年のものとされる PDFファイルが公開されています。 その内容は ISO 8601:1988 と ISO 8601:1988/Cor.1:1991 でした。 手書きで 「Related to FIPS 4-1」 と書かれていました。 >>305

[301] FIPS PUB 4-1 に対して Change Notice 1 が1996-03-25に発行されました >>302。

[303] Federal Register Change Notice #2 が1998-11-15に発行されました。 FIPS PUB 4-1 および Change Notice 1 を置き換える改訂版で、 FIPS PUB 4-2 Representation of Calendar Date for Information Interchange となりました。 >>302

[304] Change notice 2 は FIPS PUB 4-1 に編集上の訂正を加えたものとされますが、 2000年問題対策のため改正されたものだといいます。 >>302

[318] Federal Information Processing Standards Publication: for information systems - representations of local time of day for information interchange - fipspub58-1.pdf, 2017-12-04T18:27:02.000Z, 2022-03-23T03:34:39.116Z https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub58-1.pdf

JIS X 0301

[39] ISO 8601 の JIS 版が JIS X 0301 (旧 JIS C 6262) です。

• 1970-04-01 制定: JIS C 6262-1970 日付の表示(コード)
• 1973-04-01 確認
• 1976-04-01 確認
• 1977-12-01 改正: JIS C 6262-1977 日付の表示(コード)
• 1982-12-01 確認
• 1987-03-01 被移行: JIS X 0301-1977 日付の表示(コード)
• 1989-02-01 確認
• 1992-03-01 改正: JIS X 0301-1992
• 1997-06-20 確認
• 2002-08-20 改正: JIS X 0301:2002 情報交換のためのデータ要素及び交換形式―日付及び時刻の表記 Data elements and interchange formats -- Information interchange -- Representation of dates and times (MOD ISO 8601:2000)
• 2008-10-01 確認
• 2014-10-20 確認

[40] JIS X 0301 には ISO 8601 の翻訳に元号を使った日付形式の規定を組み込んでおり、 国際規格との対応の程度は MOD とされています。

[228] 「JIS X 0301 形式」 のような曖昧な言い方をする人がたまにいます。 「ISO 8601 形式」が曖昧なのと同様「JIS X 0301 形式」も曖昧です。 JIS X 0301 固有の元号を使う形式 (これ自体も複数あります。) を指している人もいれば、 ISO 8601 にある形式のいずれかを指している人もいます。

[44] :2002 5.1.3 で、文字に 平 とかを追加してるけど、 4.4 を修正してないのは初歩的なミス。 4.4 は JIS X 0201 で規定する文字を使うといっているが、 平 とかは 0201 にはない。

[172] 元号を使う場合、次の接頭辞の後2桁の数字で年号を表記します。

元号コード

[173] また元号を使う場合は年月日の区切りに - ではなく . を使います。

[221] 元号による日付の構文では、 元号を記述するものを拡張形式、 元号を省略して年月日のみとするものを基本形式としています。 どちらも区切りの . は必要です。

[222] ISO 8601 は区切り記号がないものを基本形式、 あるものを拡張形式と呼んでおり、 JIS X 0301 が拡張した元号方式だけ一貫していません。 杜撰な拡張です。

[223] 「必要によっては」元号を示してもよいと規定されていますが、 元号なしに年のみを示すのでは年が特定できません。 元号を明示するのが基本形であるべきで、 応用分野によって元号が文脈から明確であって従来の慣用などに従い元号を省略することが好ましい場面でのみ省略を許すべきでした。 情報交換目的の規格であるにも関わらず、 情報交換における標準化の意義を理解していない者が開発した規格としか思えません。

[174] 附属書1 (参考) には、明治6年の改暦より前は適用範囲外で、 「換算には特別な注意が必要」との注記があります。 ただしこの表には「M01.01.01」が「1868-01-25」に対応するなど旧暦とグレゴリオ暦の対応関係が明治初年から明治5年までも示されています。 規定本体にはそのような規定はありませんが。

[181] 年は2桁とされているので、最新元号の100年とそれ以降も表せないことになります。

[225] 改元の前後の正当な表記ではない元号と年月日の組み合わせをどう扱うか (認められるのかどうか、受信した時どう解釈するべきか) には一切言及がありません。もっとも ISO 8601 自体が値域外の値を得た時どう解釈するべきかに言及していません。 附属書1 (参考) には元号の最初と最後の日付の一覧がありますが、 あくまで参考であり、元号を使った日付表現の規定との関係性は不明です。 元号の日付の慣習的解釈に従うなら、 改元を過ぎた旧元号による記述も適当に読み替えて受け入れるべきです。 改元

[184] 改元があった場合、改正されるものと思われます。

[224] 平成は 1992-03-01 の改正で追加されたとみられます。 1989-01-08 の改元から3年も JISC は何をしていたのでしょうか。

[226] こんな具合ですから、世間でほとんど相手にされていないのも当然でしょう。 (JIS X 0301 の規定する元号を使った日付と同じ構文のものは昔からよく使われていますが、 「JIS X 0301 の規定するもの」として使われていることは稀です。) 官公庁システムなどが JIS X 0301 方式を使うと定めている可能性はあります (が元号コード方式など他の方式の方が公表されている仕様書ではよくみられます)。

[227] 主要な実装で JIS X 0301 の元号の日付に対応しているのは Ruby くらいでしょうか。その Ruby も JIS X 0301 の改正を待たずに令和に対応したようです。 令和改元

[230] 令和元年5月20日、 日本政府は改正して JIS X 0301:2019 としました >>231。改正版は既存の JIS X 0301:2002 をそのまま残し、新たに JIS X 0301:2002/AMENDMENT 1:2019 情報交換のためのデータ要素及び交換形式―日付及び時刻の表記(追補1) (Data elements and interchange formats -- Information interchange -- Representation of dates and times (Amendment 1)) を追加する形とされました。

[232] Amd.1:2019 は、既存の元号に関する規定に「令」と「R」 を追加するという最低限の変更のみ行うものでした。

[233] 令和改元では比較的迅速に対応されたといえます。 技術的な変更がなく法令改正への対応のみの形式改正であるとし、 原案委員会を設ける通常の手続きではなく経済産業省が直接原案を作成し 4月の JISC 標準第2部会に諮り、承認されました >>235。

[238] 月1回の定例スケジュールで新元号発表後最短で改正されたようです。 理論上改元後20日間は新元号を使えない空白期が生じたことになりますが、 ほぼ自明であり特別な手続きを執る必要はないと判断されたのでしょう。 (実際その通りであり、しかも閲覧も面倒な JIS の改正を急ぐよりも Webサイトの Q&A >>237 をタイムリーに更新することにリソースを集中させたのは正しい判断だったと思われます。 正式な JIS よりも公的だけど非正式であろう Web ページの記述の方が有用だというのは、 JIS の存在意義を疑わせるものではありますが...)

[268] なお、 JIS 規格票内での日付表記については、 現代日本の紀年法参照。

CNS 7648

[169] 中華民国の CNS では、 CNS 7648 (CNS X 0003) が ISO 8601 に対応します。

• [253] 70年7月20日 公布
• [254] 78年7月15日 第一次修訂
• [255] 81年10月24日 第二次修訂 (1992) : ISO 8601 TC1:1991 相当
  • [256] 81年11月 印行
  • [258] 94年10月 印行
  • [257] 101年11月 確認
• [263] 104年8月20日 第三次修訂 : ISO 8601:2004 相当
  • [264] 104年8月 印行

(日付は民国紀元)

[170] 巷では CNS 7648 は民国紀元の表現についても規定しているとされていて、 R.O.C.74-04-12 のように R.O.C. を使って表記するとされています。

[171] 民国81年改正版の附録A (参考、12ページ) の例示には確かにそのような表記例が示されていました。 しかしなぜか肝心の本文にはまったく言及がありませんでした。

[265] 民国104年改正版にはそのような例示すらありませんでした。

[266] 当初版では民国紀元を使った構文も規定されていたのでしょうか。

[178] 日本語版 Wikipedia は CNS 7648 で民国紀元が 「西暦と共に標準化されている」 >>177 と述べ、 CNS が民国紀元を定義していると誤解を招くような説明をしています。 中文版と英語版は CNS に民国紀元による表記方法があると述べるにとどまっています。 ただし英語版 Wikipedia は ROC 93-05-03 という例を示しています >>179。 中文版 Wikipedia の例は R.O.C.102-01-01 >>180、 日本語版 Wikipedia の例は R.O.C.90-09-11 >>177 で、 「.」が入っていて U+0020 は入りません。

[267] なお、 CNS 規格票内の日付表記については、 CNS 参照。

TIS 1111

[183] タイでは TIS 1111:2535 >>217 (1992) が ISO 8601 に相当しています。 TIS 1111の日時形式は、 当時の ISO 8601の日時形式とほぼ同じものですが、 西暦4桁または2桁年号のかわりに仏暦4桁または2桁年号を採用しています。

その他

[218] 中華人民共和国には ISO 8601:2000 と同内容の GB/T 7408-2005 があります。 (その前は GB/T 7408-1994 でした。) >>321 独自の規定は含まれないようです。

[322] 大韓民国には KS X ISO 8601:2010 があります。 独自の規定は含まれないようです。