Y10K and Beyond

(Y10K とその先)

このメモの位置づけ

このメモはインターネット・コミュニティーのために情報を提供するものである。 このメモはいかなるインターネット標準も定めない。 このメモの配布に制限はない。

著作権表示

Copyright (C) The Internet Society (1999). All Rights Reserved.

要旨

千年紀の終わりに近づくにつれ、いわゆる "Y2K" 問題に対して多くの注意が払われてきている。 今ではほとんど誰もが、西暦 2000 年に動かなくなってしまうように設計されたプログラムを書いた昔のプログラマーたちの先見性のなさを残念なことと考えている。 不幸なことに、Y2K に対する現在の修正が西暦 10,000 年には重大な局面を招くことは必至である。 西暦 10,000 年になるとプログラムが動かなくなるような設計が、またもや、なされているのだ。

本仕様は "Y10K" 問題に対する解決策を提供するものである。 Y10K 問題はまた、"YAK" 問題 (十六進数) とも、"YXK" 問題 (ローマ数字) とも呼ばれる。

1.　序論・議論・関連研究

プログラムや規格の多くが、日付を収容したり操作したり保守したりしている。 日付を比較したりソートしたりすることはありふれた作業である。 日付のためのさまざまなフォーマットや規格が数多く開発されてきたわけであるが、いずれも不十分であることが知られている。

初期の日付フォーマットは、日付の年号部分を表現するために 2 桁しか確保しなかった。 このフォーマットを使用するプログラムは 2000 年以降の日付を扱うときに誤りを犯してしまう。 これがいわゆる Y2K 問題である。

最も一般的な Y2K 問題の修正法は 4 桁の年号に切り替えることであった。 この修正法は、これから (9999 年まで) の約 8000 年間をカバーし、それまでには現在のプログラムはすべて使われなくなってしまうだろうと誰もが確信しているようである。 これこそがまさに現在の Y2K 問題を招いた不完全な論理と怠惰なプログラミング慣行なのだ！　プログラマーや設計者たちは、自分たちのコードはいずれ姿を消してしまうと常に決めてかかっているけれども、歴史の示唆するところによれば、コードやプログラムはしばしば彼らの意図した状況を超えてよく使われるのである。

年号を 4 桁にしてしまうと、西暦 10,000 年には動作しなくなってしまうプログラムがすぐに出来上がる。 本提案は、日付および時刻のフォーマットの諸問題の全領域をカバーする普遍的な方法で Y10K 問題と取り組むものである。

1.1　現在のアプローチ

日付および時刻をフォーマットすることに対しては数多くのアプローチが存在するが、いずれも限界がある。 2 桁年号では来年には面倒が起こる。 4 桁年号は 10,000 年に壁にぶつかる。 16 ビット年号は 65,536 年に尽きてしまう。 1970 年以来の秒数を数える 32 ビットのカウンターは 2038 年に終了してしまう [UNIX]。 ブート以来のミリ秒を数える 32 ビットのカウンターは 49.7 日後に Windows PC をクラッシュさせる [Microsoft]。

本仕様では、Y10K 問題に焦点を絞る。 というのも、それが最も一般的で、既存の規格やプロトコルの多くがその影響を受け易いからである (第 7 章⁽²⁾)。 それらの諸規格、およびそれらに基づく新たな諸提案は、コンピューター業界や政界や実業界において修正のための努力が今なされないかぎり、世界規模の深刻な問題をもたらすことになろう。

すでに、Y10K 問題を扱うために零細産業が立ち上がりつつある [YUCK]。 我々はこれらの努力を奨励するものであるが、この努力は、また、将来何年にもわたって規模と重要性とにおいてひたすら成長しうるものである。

1.2　固定フォーマットによる Y10K 修正

本稿執筆の時点で、ただひとつの提案 [Wilborne] のみが Y10K 問題を直接扱っている。 その提案では、日付はその数値をもって比較されうる十進数として表現される。 提案されているフォーマットは単純に、YYYYYMMDD、つまり 5 桁の年号である。

日付どうしの数値による比較を可能とするために、この表現法では完全に固定化された日付の表現が必要とされる。 省略可能なフィールドはなく、日付の分解能は 1 日という粒度に限定され、しかもこの解法は 100,000 年 (Y100K) に機能しなくなってしまう。

1.2.2⁽³⁾　数値による比較の限界

Y10K 問題に対しては十分なのだが、この解決法には限界がある。 年号を 6 桁に拡張しても、32 ビットのシステム (および将来の 32 ビット・システム・エミュレーター) 上では 2147481231 という数値によって表現される日付 (西暦 214748 年 12 月 31 日) 以降は動かなくなり、Y214749 問題を引き起こす。 同様に、64 ビットや 128 ビットのシステムも、いくぶん後 (それぞれ、西暦 922,337,203,685,477 年 12 月 31 日以降、西暦 17,014,118,346,046,923,173,168,730,371,588,410 年 12 月 31 日以降) のことではあるが、動作しなくなってしまう。

1.2.3　粒度の問題

固定フォーマットの日付の粒度の問題は、日付の中により大きな精度が含まれるように日付フォーマットを拡張することによって改善することができる。 しかしながら、日付どうしの数値比較には日付の固定表現が必要となるため、そうした拡張は予見されるすべての要求に対する十分な解決策を提供するものとはならない。

たとえば、精度がフェムト秒の範囲にまで拡張されれば、日付フォーマットは YYYYYMMDDHHMMSSmmmuuunnnpppfff となるであろう (年・月・日・時・分・秒・ミリ秒・マイクロ秒・ナノ秒・ピコ秒・フェムト秒)。 このフォーマットに追加された 21 桁によって、表現可能な日付の集合は制限されてしまう。 第 1.2.2 節と較べてみよう。 128 ビット形式の日付では西暦 17,014,118,346,046 年 12 月 31 日までもつとは言え、32 ビット形式や 64 ビット形式の日付ではあっという間に限度を超えてしまう。

1.2.3.1　粒度の問題の未来への敷衍

しかしながら、ムーアの法則から単純に推定すれば、フェムト秒の分解能でさえすぐに不十分なものとなることが分かる。 現在の CPU クロックの速度を未来に投影すると、わずか 30 年後にはフェムト秒のクロック速度が達成されるのである。 そして 10,000 年までには、インテル・ペンティアム MMDCLXVI のクロック速度はおよそ 10 の −1609 乗秒になると予想される。

この議論は明らかに、固定フォーマットの整数によるいかなる日付表現も将来の使用に対しては精度の点でどうやら不十分であるらしいことを示している。

1.2.3.2　浮動小数点では解決しない

日付を表現するのに浮動小数点数を使おうという誘惑は遠ざけるべきである。 より長い整数による固定フォーマットの日付の場合と同様、浮動小数点表現は、その範囲が終わってしまう不可避な時限を単に先延ばしするに過ぎない。 さらに、日付を扱う問題に対して、丸め、非正規化、非均質分布といった実数に関する周知の問題が付け加えられるだけということになってしまう。

2.　Y10K 対策の構造

いかなる Y10K 対策も、以下に述べる性格をもつべきである。

2.1　互換性

フォーマットは、既存の 4 桁の日付フォーマットと互換性をもつものでなければならない。 Y2K 対応準拠のプログラムや規格は、10,000 年になるまでの間は Y10K 対応日付を処理し続けなければならないのである。 Y10K 対応準拠プログラムは、その間に徐々に開発し、非 Y10K 対応準拠プログラムと共存させることができる。

2.2　単純さと効率

Y10K 対応日付は、10,000 年以降の日付の容易な識別を可能にするものでなければならない。 プログラム内には、Y10K 対応日付を認識し、それを旧来の日付から区別するための単純なプロシージャーがなければならない。

2.3　字句的ソート

Y10K 対応日付は、その ASCII 表現に基づいて字句的にソート可能なものでなければならない。 専用のライブラリーやプロシージャーを必要とするものであってはならない。

2.4　将来の拡張性

Y10K 対応日付は、任意の精度の日付をサポートするものでなければならず、かつ遥か未来や過去への任意の拡張をサポートするものとすべきである。 Y10K 対応日付どうしは、年代や精度が違っても直接比較したりソートしたりできなければならない。

2.4.1　環境の問題

我々の宇宙は過去も未来も有限である。 宇宙の現在の年齢は、[Zebu] によれば 100 億歳から 200 億歳の間であると見積もられている。 宇宙の終焉は、[Nigel] によれば 10 の 11 乗 (1000 億) 年後に、[Drake] によれば閉じた宇宙の場合 (ビッグクランチ) は 10 の 12 乗 (1 兆) 年後に、開いた宇宙の場合 (熱力学的死) は 10 の 14 乗 (100 兆) 年後に起こるものと見積もられている。

いずれにせよ、宇宙の寿命は (したがって可能な日付の範囲も) 有限であると一般に信じられている。

2.4.2　環境の問題を超えて

とはいえ、我々は幸運かもしれない。 実際、Y10K 対応日付は、過去でも未来でも範囲に対するいかなる制限もなしに可能な時間を表現できるのだ。

Y10K 対応準拠プログラムは、サポートする日付の範囲を予想される宇宙の寿命と矛盾しないものに制限する道を選択してもよい。 Y10K 対応準拠システムは、10 の 12 乗 (1 兆) 年前の過去から 10 の 20 乗年後の未来までの Y10K 対応日付を受け容れなければならない。 Y10K 対応準拠システムは、少なくとも過去および未来の 10 の 29 乗年間を受け容れるべきである。

3.　構文概説

Y10K 対応日付の構文は単純かつ印字可能な ASCII 文字で構成される。 構文および文字は、Y10K 対応フォーマットで表現された日付の単純な字句的ソート順序をサポートするように選ばれている。 すべての Y10K 対応日付はこれらの規則に適合しなければならない。

あらゆる Y10K 対応日付は、Y10K 対応年号で始まるものでなければならない。 年号のあとに、任意の数字列が続いてもよい。 それらの数字は MMDDHHMMSSmmmuuunnnpppfff... (月・日・時・分・秒・ミリ秒・マイクロ秒・ナノ秒・ピコ秒・フェムト秒などなど——日付の左から右へ行くに従って数字の有意性は減少する) と解釈される。

日付および時刻はすべて国際原子時 (TAI) [NRAO] と相関関係のあるものでなければならない。

日付どうしを比較するとき、ある日付は、それを接頭辞としてもつ他のすべての日付に先立つ。 したがって、"19990401000000" という日付は "19990401000000000" という日付よりも先にくる。 とくに、YYYYMMDD の形式の日付は、正確にその日の始まりを表わすものと解釈され、その日のうちに含まれる他のどんな日付よりも先行する。

3.1　西暦 1 年から 9999 年まで

現在の 4 桁の年号の構文は 1000 年から 9999 年までのすべての年号をカバーするものである。 これらの年号は 4 桁の十進数として表現される。 1000 年より以前の年号には、それを 4 桁にするために頭に 0 が付加されなければならない。 旧来の Y1K [Mike] 以前の日付を含むファイルは変換しなければならないことになる。

3.2　西暦 10,000 年から 99,999 年まで

9999 年より先の日付を表現するには 4 桁は十分なものではない。 このため、10,000 年から 99,999 年までの年号はすべて 5 桁で表現し、その先頭に文字 "A" をつける。 すなわち、10,000 年は "A10000" になり、99,999 年は "A99999" になる。 ASCII 順では "A" は "9" の後になるため、5 桁の年号をもつすべての日付は 4 桁の年号をもつすべての日付より後になる (たとえば、"A10000" は "9999" より後にソートされる)。 これにより我々の望むソートおよび比較の振る舞いが得られる。

3.3　西暦 100,000 年から 10 の 30 乗年の直前まで

第 3.2 節の単純な一般化により、6 桁の年号には文字 "B" を前につけ、7 桁の年号には "C" を前置し、以降も同様にする。 ASCII 文字の 26 個の大文字を使うことにより、10 の 30 乗年の直前までのすべての年号をカバーすることができる (表現可能な年号の最後は "Z999999999999999999999999999999" である)。 繰り返すが、ASCII 文字はアルファベット順にソートされるため、すべての日付が適切にソートされる。

3.4　西暦 10 の 30 乗年以降 (Y10**30)

第 2.4.1 節で論じたように、宇宙の終焉は都合よく 10 の 30 乗年より以前に起こるものと予想されている。 しかしながら、現在の Y2K 問題から学ぶべき教訓がひとつあるとすれば、それは仕様や規約が予想される環境よりも長生きする傾向にあるということである。 それゆえ、日付表現の問題を一度完全に解決しておくことが肝要であると我々は考える。

3.4.1　Y10**30 問題への単純なアプローチ

単純な解決策は、10 の 30 乗年から 10 の 56 乗年までのすべての年号に対して、その前に単一の "^" (キャレット) を付加することである (キャレットは ASCII 順ではすべての英字の後にソートされる)。 したがって、年号 "Z999999999999999999999999999999" の次の年号は "^A1000000000000000000000000000000" になる。 同様に、10 の 56 乗年から 10 の 82 乗年までのすべての年号に対しては、キャレットをもうひとつ付加する。 すなわち、年号 "^Z99999999999999999999999999999999999999999999999999999999" の次の年号は "^^A100000000000000000000000000000000000000000000000000000000" である。 この図式は、年号の範囲における 10 の 26 乗という因数が増えるごとにキャレットをひとつ付加することによって際限なく拡張することができる。

このアプローチでは、日付の中で年号を表現するのに用いられている数字の桁数は次のように簡単に求めることができる。

26 * <number of '^'> + ASCII(<prefix letter>) - ASCII('A') + 5

注意 — このアルゴリズムは単なる情報提供の目的のために示すものであり、真の解決策へ導く経路を示すためのものである。 Y10K 対応日付はこのフォーマットを使用してはならない。 Y10K 対応日付は次節に示すフォーマットを使用しなければならない。

3.4.2　Y10**30 問題へのスペース効率のよいアプローチ

第 3.4.1 節の解決法は年号の桁数に関してスペース効率のよいフォーマットではない。 接頭辞の長さが年号の長さに対して線形的に増大してしまうのである (年号の長さ自身は時間の経過に対して対数的に増大する)。 そのため、Y10K 対応フォーマットの日付では、改良型の、よりコンパクトな年号の桁数の符号化法を使用する。

3.4.2.1　西暦 10 の 30 乗年から 10 の 56 乗年まで

第 3.4.1 節におけるように、年号の前に単一の "^" と英字とをつける。

3.4.2.2　西暦 10 の 56 乗年から 10 の 732 乗年まで

年号の前に 2 つのキャレット ("^^") と 2 つの英字をつける。 英字は 2 桁の 26 進数をなし、年号の桁数から 57 を引いた値を表わす。 したがって、年号 "^Z99999999999999999999999999999999999999999999999999999999" の次の年号は "^^AA100000000000000000000000000000000000000000000000000000000" となる。 2 つのキャレットで始まる年号によって表現できる最後の年号は (10 ** 732) − 1 年、すなわち、"^^ZZ999...999" (2 つのキャレットと 2 つの Z、それに 732 個の 9 が続いたもの) である。

2 桁の接頭辞に基づいて年号の桁数を表わす式は次のとおり。

26 * (ASCII(<prefix letter1>) - ASCII('A')) +
      ASCII(<prefix letter2>) - ASCII('A') + 57

3.4.2.3　西暦 10 の 732 乗年から 10 の 18308 乗年まで

次の年号ブロックは 3 つのキャレット ("^^^") とそれに続く 3 桁の 26 進数をなす 3 つの英字とによって与えられる桁数をもつ。 年号の桁数は次の式によって与えられる。

676 * (ASCII(<prefix letter1>) - ASCII('A')) +
 26 * (ASCII(<prefix letter2>) - ASCII('A')) +
       ASCII(<prefix letter3>) - ASCII('A') + 733

3.4.2.4　Y10K 対応日付の一般的フォーマット

一般に、Y10K 対応年号にひとつでも英字が含まれていれば、日付の年号部分の桁数は次の式によって与えられる。

base26(fib(n) letters) + y10k(n)

ここで、"n" は先頭のキャレットの数であり、fib、base26、y10k の各関数は以下の循環関係によって定義される。

fib(n) は標準フィボナッチ数列である。

fib(0) = 1
fib(1) = 1
fib(n+2) = fib(n) + fib(n+1)

base26(m letters) は A から Z の範囲の英字 m 個によって表現される 26 進数である。

base26(letter) =  ASCII(<letter>) - ASCII('A')
base26(string letter) = 26 * base26(string) + base26(letter)

y10k(n) は数列を正しく調整するために必要な補正係数である。

y10k(0) = 5
y10k(n+1) = 26 ** fib(n) + y10k(n)

年号の中に英字がひとつもなければ、年号の桁数は次のとおり。

4

この年号フォーマットはスペース効率のよいものである。 年号の桁数を与える接頭辞の長さは年号の桁数に対して対数的にしか伸びない。 また、接頭辞に先行するキャレットの数も接頭辞の桁数に対して対数的にしか伸びない。

3.5　紀元前の年号

未来のすべての年号のためのフォーマットを手にした今、「負の」年号について議論しよう。 負の年号は「Y10K 対応の補数」の形式で表現される。 Y10K 対応の補数の年号は以下のように計算される。

たとえば、紀元前 1 年は "/9998" によって表現される。 この変換は以下の規則を適用することによって果たされる。

最も早い 4 桁の紀元前年号 (紀元前 9999 年) は "/0000" になり、その前年 (紀元前 10000 年) は "*Z89999" になる。 最も早い 5 桁の紀元前年号 (紀元前 99999 年) は "*Z00000" になり、その前年 (紀元前 100000 年) は "*Y899999" になる。以下同様。

これらの規則は紀元前の日付に対し望ましいソート順序を与える。 たとえば、以下の日付は次のとおりに変換されソートされる。

3.6　Y10K 対応日付の制約

正しい Y10K 対応日付の値に制限はない。 Y10K 対応準拠プログラムは、正当な日付として構文的に正しい Y10K 日付であればどんなものでも受け容れなければならない。 いかなる Y10K 対応日付もその末尾に "0" を付加することができる。 これは等価な日付を与えるが、もとの日付の直後にソートされ、もとの日付の後の瞬間を表現する。

以下はすべて A10000 の最初の瞬間の正しい表現である (ソート順)。

A1
A10000
A1000001
A100000101000000
A1000001010000000000000000000000

同様に、以下はすべて、A99999 の最後の瞬間より後、かつ B100000 の最初の瞬間より前の時刻の正しい Y10K 対応日付である (ソート順)。

A999991231250000
A999991232
A999992
A9999999999
A99999999990000000000000

4.　ABNF

以下の ABNF [Crocker] は、Y10K 対応年号の形式的構文を示したものである。

先頭部分の文字定義は、その字句照合順 (ASCII 順) に示されている。

exclamation = '!'
star        = '*'
slash       = '/'
digit       =  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
letter      =  A | B | C | D | E | F | G | H | I | J | K | L | M |
               N | O | P | Q | R | S | T | U | V | W | X | Y | Z
caret       = '^'

year     = [*(caret | exclamation) | star | slash ] [ *letter ]
          *digit
month    = 2digit
day      = 2digit
hour     = 2digit
minute   = 2digit
second   = 2digit
fraction = *digit
date     = year [ month [ day [ hour [ minute [ second [ fraction
          ]]]]]]

5.　未解決の問題

この仕様の適用範囲を超えたところにある日付比較の問題は少なくない。

6.　影響を受ける規格

現在の規格および RFC の多くは 4 桁の年号を使用しており、本提案によって影響を受ける。

以下の規格は内部で年号を 16 ビットの数値 (0～65536) として表現しており、本提案の影響を受ける。

次の ISO 規格が影響を受ける。

8.⁽⁴⁾　セキュリティーに関する考慮事項

Y10K 対応日付は、それが用いられるすべてのプログラムのセキュリティーを向上させるものとなろう。 プログラム内のエラーの多くは違法な入力の解析中にオーバーフローすることであると突き止められている。 日付のために固定サイズの記憶領域を割り当てるプログラムは、より大きな日付が与えられたときにエラーを露見させることになる。 このエラーは悪辣なハッカーに悪用されてそれらのプログラムを走らせるシステムのセキュリティーを危うくしうるものである。 Y10K 対応日付は任意の長さの文字列であるため、プログラムをオーバーフローさせる方法がない。

加えて、正の Y10K 対応日付は人間にとって比較し易く、間違いを犯しにくいものである。 予測されている宇宙の終焉の 3 つの日付——"H100000000000"、"I1000000000000"、"K100000000000000"——を比較するには、0 を数えるよりも先頭の文字を見るほうが簡単である。 これは人間の不注意による間違いを削減することになる。 このメリットは、大きな日付がもっと普通になればより顕著なものとなろう。

残念ながら、負の Y10K 対応日付は判読がやや困難である。 しかし、宇宙の現在の年齢をその終焉予測と比較すれば、負の日付よりも正の日付のほうが多いことは明らかである。 さらに、人間の歴史における負の日付の数は今のところ正の日付の数よりも多いけれども、負の日付の数が変わらないのに対し、正の日付の数は限られていない。

9.　結論

Y10K 問題の対策に果敢に取り組むことに早すぎるということはない。 本仕様はこの問題に対し簡潔でエレガントかつ有効な解決策を与えるものである。

10.　参考文献

11.　著者連絡先

Steve Glassman
Compaq Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301 USA

Phone: +1 650-853-2166
EMail: steveg@pa.dec.com

Mark Manasse
Compaq Systems Research Center
130 Lytton Avenue
Palo Alto, CA 94301 USA

Phone: +1 650-853-2221
EMail: msm@pa.dec.com

Jeff Mogul
Compaq Western Resarch Lab
250 University Avenue
Palo Alto, CA 94301 USA

Phone: +1 650-617-3300
EMail: mogul@pa.dec.com

12.　著作権宣言全文

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書およびその翻訳は、全体または一部について、いかなる種類の制約も受けることなく、複製および他者への供与ができるほか、これについて注釈し、または他の方法で解説し、あるいはその実装を助ける派生的著作を用意、複製、出版、および配布することができる。 ただし、上記の著作権表示およびこの一節が当該の複製および派生的著作のすべてに含まれるものとする。 一方、この文書自体は、著作権表示を削除したり Internet Society ないし他のインターネット機関への参照を削除したりするなどのいかなる方法によっても改変してはならない。 ただし、インターネット標準の開発の目的のために必要とされるインターネット標準化プロセスの著作権の手続きに従う場合、および英語以外の言語に翻訳するのに必要とされる場合を除く。

上で与えた制限つきの許諾は恒久のものであり、Internet Society またはその後継者ないし譲受人によって取り消されることはない。

この文書およびここに含まれる情報は「現状有姿」方式で提供されるものであり、Internet Society および Internet Engineering Task Force は、明示的であるか黙示的であるかを問わず、一切を保証しない。 ここでいう保証には、ここにある情報の利用がいかなる権利をも侵害しないという保証や、特定の目的に対する市場性ないし適合性についての暗黙の保証が含まれるが、それらのみに限定されない。

【訳注】

※ 原文における明らかな誤りは訂正した。