RFC 2550

1万年問題

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

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

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

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

対処済みの日時形式

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

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

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


[22] MEW3 PktCDateLib, , 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] 出版された4月1日のRFCである RFC 2550 は、インターネットにおける1万年問題を扱っており、 1万年問題を解決したRFC 2550の日時形式を定義しています。

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

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

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

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


[36] Y10K dateTAI日時を表します。 >>4

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

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


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

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


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

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

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

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

  1. *
    1. ^
  2. +
    1. ASCII大文字

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

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

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

  1. [70] y を、B.C.E. の年番号に設定します。
  2. [71] s を、 y 年の Y10K year に設定します。
  3. [72] sASCII大文字を、すべて26進数補数に置き換えます。
    • [73] 例えば A → Z、B → Y
  4. [74] sASCII数字を、すべて10進数補数に置き換えます。
    • [75] 例えば 0 → 9、1 → 8
  5. [76] s^ を、すべて ! で置き換えます。
  6. [77] s が4桁のASCII数字列の場合、先頭に / を付けます。
  7. [78] s の先頭が !/ でない場合、 先頭に s を付けます。
  8. [79] s を返します。
[85] この仕組みは補数を使うため人間の直感的な読解が困難です。 日時の比較文字列の比較を一致させるためこのような方式を採用しています。 過去の日時よりも今後の日時の方が多いのだから、 この程度の不便は許容できるとされています >>4

[84] の桁数はこのように定められていますが、それに満たなくても妥当な Y10K date ではあるとされます。末尾に 0 を書き足したものと同じ日付を表すとされます。 例えば A1A10000 と同じで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桁だけ書いた例も示されています。 例えば A999992A9999920 (99999年20月) を表します。 >>4


[40] 日時の比較では、 部分文字列になる日付はより小さいとします。 >>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

未対応の日時形式

[10] RFC 3339の日時形式は4桁固定で、西暦1万年問題未対応です。

[29] インターネットメールの日時形式は4桁以下で、西暦1万年問題未対応です。

関連

[9] 将来の日時も参照。

メモ

[1] 西暦10000年問題 - Wikipedia ( 版) http://ja.wikipedia.org/wiki/%E8%A5%BF%E6%9A%A610000%E5%B9%B4%E5%95%8F%E9%A1%8C (名無しさん)

[2] Year 10,000 problem - Wikipedia, the free encyclopedia ( 版) http://en.wikipedia.org/wiki/Year_10%2C000_problem (名無しさん)

[3] 一万年問題のポイントの1つは、そんな先のことまで考えずとも、 もっと若い年号すらまともに扱えない (のがほとんどである) ことではありますまいか。

[30] 10000年問題 ‐ 通信用語の基礎知識, https://www.wdic.org/w/TECH/10000%E5%B9%B4%E5%95%8F%E9%A1%8C

[20] 9340年問題 ‐ 通信用語の基礎知識 () http://www.wdic.org/w/TECH/9340%E5%B9%B4%E5%95%8F%E9%A1%8C