1万年問題

[11] 西暦1万年問題は、4桁以下で年を扱うシステムにおいて、 10000年以上の日時を扱えないという桁溢れ問題です。

[12] 2桁で年を扱うシステムに関する西暦2000年問題のついでに注目され、一部で対策が行われましたが、完全解決には至っていません。

[19] はるか先の日付であり、将来の日時として取り扱うことすらほとんどないため、あまり真剣には取り組まれていません。

[21] 年問題の本質とは何かを考えさせられます。年問題

対処済みの日時形式

[6] ISO 8601 は、 (4桁の構文の自然な拡張ではない) 展開表現により1万年問題に対処しています。

[7] xs:dateTime は展開表現ではなく既存の構文の自然な拡張によって1万年問題に対処しています。 (意図的かどうかは書かれていませんが) ISO 8601 に違反しますが、 XML Schema は ISO 8601 を規定ではなく参考として参照しているので、構わないと考えているのでしょう。

[8] ISO 8601 から派生した独自の構文であるHTMLの日時形式は、展開表現ではなく既存の構文の自然な拡張によって1万年問題に対処しています。

[22] MEW3 PktCDateLib, 2021-05-24T08:18:39.000Z, 2000-12-02T20:56:12.909Z https://web.archive.org/web/20001202204800/http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate/index.html

[23] この PktCDateLib という Palm OS 用のライブラリーは RFC 2550 が西暦1万年問題に対処する従来手法の唯一知られる例として引いていました。 >>4

[24] このライブラリーは「YYYYMMDD」式の日付形式を採用していました。 >>22

[25] この方式の (「DDMMYYYY」のような他の方式に対する) 利点として、そのままの大小が日の大小になることと、年を5桁に拡張して西暦1万年問題対策とできることが挙げられていました。 >>22

[27] 年月日順が普通の日本で生活していると考えにくいですが、欧米人にとって年月日をこの順序で並べるだけのことにも理由をわざわざ書く必要があったようです。

[26] ただし本ソフトウェアは old Palm epoch を使っていたので、西暦2031年までしか扱えませんでした。 >>22

[28] 当然ながら5桁に拡張しても99999年までしか記述できません。次は6桁に拡張する必要が出てきます。

RFC 2550 の日時形式

[5] 1999-04-01に出版された4月1日のRFCである RFC 2550 は、インターネットにおける1万年問題を扱っており、 1万年問題を解決したRFC 2550の日時形式を定義しています。

[4] RFC 2550 - Y10K and Beyond (2017-03-19 16:23:49 +09:00) https://tools.ietf.org/html/rfc2550

[13] 単に年の桁数を増やすだけでなく、 ASCII 順での整列が日時の整列となることを重視しています。

[14] 紀元前にも対応しています。

[15] 年のみならず、月まで、日まで、時まで、分まで、秒まで、任意の桁数の秒の小数部までと任意の精度の日時を表現できます。粗い日時と細かい日時が混在する場合の整列は、 ASCII文字列の整列と同様に、粗い日時が細かい日時の最初の瞬間の前に来ます。

[16] 区切りの記号を使わず、年と秒の小数部以外は固定の桁数の ASCII数字列となっています。どの部分も最大値の規定はなく、実在する日時の最大値を超えた時は、次の存在する日時の直前の瞬間を表すことになっています。 (例えば A999991232 (12月32日) は B100000 の前の瞬間を表しています。)

[36] Y10K date は TAI の日時を表します。 >>4

[31] Y10K date 構文は無限の過去から無限の未来まで記述できますが、実装は宇宙の寿命を考慮した限界を設けて構わないとされています。すなわち、 >>4

[32] Y10K compliant program は、宇宙の想定される寿命に整合する形で対応する日付の範囲を制限して構いません。
[34] Y10K compliant system は、最低、過去および未来に 10²⁹ 年間の日付を受理するべきです。
[33] Y10K compliant system は、過去 10¹² 年間、未来 10²⁰ 年間の Y10K date を受理しなければなりません。

[35] 宇宙論の研究の進展でこのへんの規定は改訂する必要があるかもしれませんね?

[37] Y10K date は印字可能ASCII文字の列です。 >>4

[38] Y10K date は、 Y10K year の後に年内の日時を続けたものです。 >>4

[43] Y10K year は、年番号によって記述方法が違います。 >>4

[56] 1 年とそれ以後は、次のように記述します。
- [44] [ 1, 999 ] は、0埋めして4桁の10進数のASCII数字列で表します。
- [45] [ 1000, 9999 ] は、そのまま4桁の10進数のASCII数字列で表します。
- [46] 10000 以上の年は、 ASCII数字列の前に、その桁数で決まる記号を付けます。
[68] 1 年よりも前は、西暦紀元前の年を変換して記述します (>>69)。

[52] 仕様書は4桁の時以外、 ASCII数字列は10進数だと明記していません。

[47] 年が 10000 以上の年は、 A10000, ..., Z999999999999999999999999999999, ^A1000000000000000000000000000000, ..., ^Z99999999999999999999999999999999999999999999999999999999, ..., ^^AA100000000000000000000000000000000000000000000000000000000, ... と表します。 >>4 この先頭にある桁数を表す記号列は、 ASCII文字列としての比較と年の大小が一致するように決められています。

[48] 先頭の記号列は、0個以上の ^ の後に、 1個以上の ASCII大文字を続けたものです。 >>4

*
1. ^
+
1. ASCII大文字

[64] ただし ^ と ASCII大文字の数には制約があります。 >>4

[65] n : ^ の数
[66] m : ASCII大文字の数
[67] m = fib(n)
[55] fig(n) : 標準フィボナッチ数列
- fib(0) = 1
- fib(1) = 1
- fib(n + 2) = fib(n) + fib(n + 1)

[53] 先頭の記号列から年の桁数は次のように決まります。 >>4

[54] 年の桁数 = base26(ASCII大文字列) + y10k(n)
[57] base26(文字列) : ASCII大文字で表される26進数
- [58] base26(文字) = ASCII(文字) - ASCII(A)
  - [59] ASCII(文字) : 文字の ASCII 符号位置
- [60] base26(文字列 文字) = 26 × base26(文字列) + base26(文字)
[61] y10k(n)
- [62] y10k(0) = 5
- [63] y10k(n + 1) = 26^fib(n) + y10k(n)

[69] 1 年よりも前の年は、次の手順の結果で表します。 >>4

[70] y を、B.C.E. の年番号に設定します。
[71] s を、 y 年の Y10K year に設定します。
[72] s の ASCII大文字を、すべて26進数の補数に置き換えます。
- [73] 例えば A → Z、B → Y
[74] s のASCII数字を、すべて10進数の補数に置き換えます。
- [75] 例えば 0 → 9、1 → 8
[76] s の ^ を、すべて ! で置き換えます。
[77] s が4桁のASCII数字列の場合、先頭に / を付けます。
[78] s の先頭が ! か / でない場合、先頭に s を付けます。
[79] s を返します。

[85] この仕組みは補数を使うため人間の直感的な読解が困難です。日時の比較と文字列の比較を一致させるためこのような方式を採用しています。過去の日時よりも今後の日時の方が多いのだから、この程度の不便は許容できるとされています >>4。

[84] 年の桁数はこのように定められていますが、それに満たなくても妥当な Y10K date ではあるとされます。末尾に 0 を書き足したものと同じ日付を表すとされます。例えば A1 は A10000 と同じで1万年を表します。 >>4

[80] 年内の日時は、任意個のASCII数字を続けたものです。先頭から順に、月、日、時、分、秒、ミリ秒、マイクロ秒、ナノ秒、ピコ秒、フェムト秒とどんどん細かい単位を表していきます。 >>4

[50] 月から秒までは、それぞれ2桁で表します。 >>4

[51] 仕様書上明記されていませんが、すべて10進数で表したものです。 1桁の数値は0埋めします。

[39] 月から秒までの数値には値域の制限がなく、 00 から 99 まですべてが構文上認められています >>4。

[81] 例えば A99999 の最後の瞬間と B100000 の最初の瞬間の間に A999991232 が入ると例示されています >>4。

[82] これが現実世界の時間軸で何に当たるものか不明ですが...

[83] 構文上は2桁単位での指定が義務付けられているのですが、規定本文ではそうでもないようなことが書かれていて、実際上1桁だけ書いた例も示されています。例えば A999992 は A9999920 (99999年20月) を表します。 >>4

[40] 日時の比較では、部分文字列になる日付はより小さいとします。 >>4

[41] 例えば 19990401000000 < 19990401000000000 >>4

[49] その他はASCII文字列の比較が日時の比較と一致します。

[17] 4月1日に発行された RFC であり、検討するのも野暮な話かもしれませんが、現実的にはあまり使い勝手の良い日時形式ではないかもしれません。 (RFC 2550 はいい性質を供えたよい方式だと謳っていますがねw)

[18] 文字列としての整列を重視する余り、可読性を著しく落としていますし、 1万年以上で使われる英字や記号は人間が扱うには難しすぎる (ミスする可能性が高い) ものです。整数時刻系などの完全に機械処理向けの日時形式を使わず、人間向けの年月日の構造を残した日時形式を敢えて採用する場面では、こうした欠点は致命的です。

[42] 西暦年やグレゴリオ暦、24時間制が暗黙の前提となっています。それ以外の紀年法や暦法や時法には対応していません。

[86] RFC 2550 は、未解決の課題として、 Aztec, Bhuddist, Jewish, Muslim, and Hittite calendars の日付など異なる calendar system の日付は直接は比較できない、まず common calendar に変換しなければならない、と述べていました。 >>4

[87] どうやら著者らはグレゴリオ暦等以外の日付の記述には使えるが、比較には支障があると認識していたようです。実際には問題はそう単純ではありません。例えば閏月の月名は整数化できませんし、元号やチベット暦の年数も整数化できません。

[88] RFC 2550 は、将来年の re-numbering があると対応できない、新たな「Year 0」が出現して常用に供されると古い日付は調整しなければならなくなる、 >>4 としていました。

[89] つまり将来の改元の可能性は視野に入れつつ (ただし東洋式の元年ではなく0年から起算)、その場合に構文はそのままで元期を変えるという構想だったようです。

[90] 更には、年や日などが地球中心で将来の太陽系の終焉後に問題となり得ること、将来の惑星間、銀河間の時刻同期手法の合意が未形成であること、宇宙の終焉後の日付のゆくえが不透明であることが、課題として指摘されていました。 >>4