[Joke-RFC] RFC2550 Y10K問題とその先

# はじめに

* この文書は [RFC2550](https://www.rfc-editor.org/rfc/rfc2550.txt) を勉強と好奇心のため適当に訳したものです。
* 翻訳の正確さは全く保証しません。
* 誤字誤訳等の指摘はいつでも大歓迎です。

# Y10K and Beyond（Y10K問題とその先）

* Network Working Group
* Request for Comments: 2550
* Category: Stinkards Track

- S. Glassman
- M. Manasse
- J. Mogul
- Compaq Computer Corporation
- 1 April 1999

## Status of this Memo（このメモの位置づけ）

> This memo provides information for the Internet community.
> It does not specify an Internet standard of any kind.
> Distribution of this memo is unlimited.

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

## Copyright Notice

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

## Abstract（要約）

> As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem.
> Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000.
> Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail.
>
> This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem (Roman numerals).

ミレニアムの終わりを前にして、いわゆる「Y2K」問題が注目されている。
2000年に問題となるように設計されたプログラムを書いた昔のプログラマーたちの短絡的な思考を、いまや誰もが悔やんでいる。
残念ながら、現在のY2K問題への対策は、1万年後にはそのプログラムが再び問題となるように設計されており、必然的に危機を招くことになるだろう。

本仕様は、この「Y10K」問題に対する解決策を提供するもので、「YAK」問題（16進数）、「YXK」問題（ローマ数字）とも呼ばれている。

## 1. Introduction, Discussion, and Related Work（序論、議論、関連研究）

> Many programs and standards contain, manipulate and maintain dates.
> Comparing and sorting dates is a common activity.
> Many different formats and standards for dates have been developed and all have been found wanting.
>
> Early date formats reserved only two digits to represent the year portion of a date.
> Programs that use this format make mistakes when dealing with dates after the year 2000.
> This is the so-called Y2K problem.
>
> The most common fix for the Y2K problem has been to switch to 4-digit years.
> This fix covers roughly the next 8,000 years (until the year 9999) by which time, everyone seems convinced that all current programs will have been retired.
> This is exactly the faulty logic and lazy programming practice that led to the current Y2K problem!
> Programmers and designers always assume that their code will eventually disappear, but history suggests that code and programs are often used well past their intended circumstances.
>
> The 4-digit year leads directly to programs that will fail in the year 10,000.
> This proposal addresses the Y10K problem in a general way that covers the full range of date and time format issues.

多くのプログラムおよび標準は、日付を含み、操作し、保持する。
日付を比較したり、並べ替えたりすることは、一般的な活動である。
日付に関するさまざまなフォーマットや標準が開発されたが、どれも不十分なものである。

初期の日付形式は、日付の年部分を表すのに2桁しか予約していなかった。
この形式を使用するプログラムは、2000年以降の日付を扱うときに間違いを起こす。
これがいわゆるY2K問題である。

Y2K問題に対する最も一般的な対策は、年を4桁に変更することだ。
この対策は、今後約8000年（9999年まで）をカバーするもので、その間に現在のプログラムはすべてリタイアしていると誰もが確信しているようである。
これはまさに、現在のY2K問題を引き起こした誤った論理と怠惰なプログラミングの実践なのだ！
プログラマーや設計者は、自分たちのコードはいずれ消えるものだと常に思っているが、歴史が示すように、コードやプログラムはしばしば意図した状況をはるかに超えて使われることがある。

4桁の年号は、1万年後に問題を起こすプログラムに直結する。
本提案は、日付と時刻のフォーマットの問題全般をカバーする一般的な方法で、Y10K問題に対処するものである。

### 1.1 Current approaches（現時点の取り組み）

> A large number of approaches exist for formatting dates and times.
> All of them have limitations.
> The 2-digit year runs into trouble next year.
> The 4-digit year hits the wall in the year 10,000.
> A 16-bit year runs out in the year 65,536.
> A 32-bit counter for the number of seconds since 1970 [UNIX] wraps in 2038.
> A 32-bit counter for the number of milli-seconds since booting crashes a Windows (TM) PC in 49.7 days [Microsoft].
>
> In this specification, we focus on the Y10K problems since they are most common and a large number of existing standards and protocols are susceptible to them (section 7).
> These standards, and new proposals on their way, will lead to a serious world-wide problem unless efforts are made now to correct the computing, government, and business communities.
>
> Already, a small cottage industry is popping up to deal with the Y10K problem [YUCK].
> We encourage these efforts and, in the coming years, this effort can only grow in size and importance.

日付と時刻の書式設定には多くのアプローチが存在する。
そのどれにも限界がある。
2桁の年号は来年（訳注：このRFCは1999年発行）になると問題が発生する。
4桁の年は10,000年に壁に突き当たる。
16ビットの年は、65,536年で限界になる。
1970年からの秒数を表す32ビットのカウンタ [UNIX] は2038年に終了する。
起動してからのミリ秒の32ビットカウンタは、Windows (TM) PCを49.7日でクラッシュさせる　[Microsoft]。

本仕様書では、Y10K問題が最も一般的であり、多くの既存の標準とプロトコルがその影響を受けやすいため、Y10K問題に焦点を当てる(7章)。
これらの標準や、現在進行中の新しい提案は、コンピューティング、政府、ビジネスコミュニティが今すぐ修正する努力をしない限り、深刻な世界規模の問題につながるだろう。

すでに、Y10K問題に対処するための小さなコテージ産業が出現している [YUCK]。
私たちはこのような努力を奨励し、今後数年間で、この努力は規模と重要性を増すばかりだろう。

### 1.2 A Fixed Format Y10K Fix（固定長フォーマットによるY10K問題の解決方法）

> At the time of this writing, only one proposal [Wilborne] directly deals with the Y10K problem.
> In that proposal, dates are represented as decimal numbers with the dates compared numerically.
> The proposed format is simply YYYYYMMDD - i.e. 5-digit years.
>
> To allow numerical comparison of dates, this representation requires a completely fixed representation for the date.
> There can be no optional fields, the date resolution is limited to the granularity of one day, and this solution fails in the year 100,000 (Y100K).

この記事の執筆時点では、Y10K問題を直接扱っている提案は1つだけである [Wilborne]。
その提案では、日付は10進数として表され、日付は数値で比較される。
提案された形式は、単純に`YYYYYMMDD`、つまり5桁の年だ。

日付の数値比較を可能にするには、この表現には日付の完全に固定長の表現が必要である。
オプションのフィールドはなく、日付の解決は1日の精度に制限されており、このソリューションは100,000年（Y100K）で問題が発生する。

#### 1.2.2 Limitations of Numerical Comparison（数値比較の限界）

> While sufficient for the specific Y10K problem, this solution is limited.
> Even if extended for 6-digit years, it fails on 32-bit systems (and future 32-bit system emulators) after the date represented by the number 2147481231 (December 31, 214748) leading to a Y214749 problem.
> Similarly, 64-bit and 128-bit systems also will fail, although somewhat later (after December 31, 922,337,203,685,477 and December 31, 17,014,118,346,046,923,173,168,730,371,588,410 respectively).

特定のY10K問題には十分ではあるが、この解決策には限界がある。
6桁の年号に拡張しても、`2147481231`（214748年12月31日）以降の32ビットシステム（および将来の32ビットシステムのエミュレータ）では、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 Granularity Issues（精度の問題）

> The granularity problems of a fixed format date can be improved by extending the date format to include greater precision in the date.
> However, since numerical comparison of dates requires a fixed representation date, an extended format can not provide sufficient resolution for all foreseeable needs.
>
> For instance, if the precision were extended to the femto-second range the date format would become YYYYYMMDDHHMMSSmmmuuunnnpppfff (year, month, day, hour, minute, second, milli-second, micro-second, nano-second, pico-second, and femto-second).
> The additional 21 digits of this format limit the set of representable dates.
> Compared to 1.2.2, the 32-bit and 64-bit forms of the date are instantly exceeded, while the 128-bit version would be viable - expiring on December 31, 17,014,118,346,046.

固定長フォーマットの日付の精度の問題は、日付の形式を拡張して、より精度の高い日付を含めることで改善することができる。
しかし、日付の数値比較は日付を固定的に表現する必要があるため、拡張されたフォーマットでは予想されるすべてのニーズに対して十分な解像度を提供することはできない。

例えば、フェムト秒単位まで精度を上げると、`YYYYMMDDHHMMSSmmmuuunnnpppfff`（年、月、日、時、分、秒、ミリ秒、マイクロ秒、ナノ秒、ピコ秒、フェムト秒）のようになる。
この形式では、21桁の数字が追加されるため、表現可能な日付が制限される。
1.2.2項と比較すると、32ビットと64ビット形式の日付は即座に超過し、128ビット版は実行可能である —— 17,014,118,346,046年12月31日に問題が起きる。

##### 1.2.3.1 Extrapolation of Future Granularity Issues（将来の精度問題の予測）

> However, a simple extrapolation of Moore's law shows that even femto-second resolution will soon be inadequate.
> Projecting current CPU clock speeds forward, a femto-second clock speed will be achieved in only 30 years.
> And, by the year 10,000 the projected clock speed of the Intel Pentium MMDCLXVI (TM) will be approximately 10 \*\* (-1609) seconds.

> This discussion clearly shows that any fixed-format, integer representation of a date is likely to be insufficiently precise for future uses.

しかし、ムーアの法則を単純に外挿すると、フェムト秒の分解能もまもなく不十分なものになる。
現在のCPUのクロックから将来予測すると、フェムト秒のクロックスピードが達成されるのはわずか30年後である。
また、1万年後の Intel Pentium MMDCLXVI（TM）（訳注：ローマ数字で 2666）のクロックスピードは、約 $10^{-1609}$秒になると予測されている。

このように、固定フォーマットの整数表現では、将来の利用において十分な精度が得られない可能性があることは明らかである。

https://ja.wikipedia.org/wiki/%E3%83%A0%E3%83%BC%E3%82%A2%E3%81%AE%E6%B3%95%E5%89%87

##### 1.2.3.2 Floating Point Is No Solution（浮動小数点は解決策とはならない）

> The temptation to use floating point numbers to represent dates should be avoided.
> Like the longer fixed-format, integer representations of the date, floating point representations merely delay the inevitable time when their range is exceeded.
> In addition, the well known problems of real numbers - rounding, de-normalization, non-uniform distribution, etc. - just add to the problems of dealing with dates.

浮動小数点数で日付を表現する誘惑は避けるべきだろう。
より長い固定長フォーマットの整数表現と同様に、浮動小数点表現は、その範囲を超えたときに避けられなくなる問題を遅らせるだけだ。
さらに実数のよく知られた問題 ——丸め、正規化解除、不均な分布など—— が、実数を扱う際の問題をさらに大きくし、日付を扱う際の問題に拍車をかけるだけである。

## 2 Structure of Y10K Solution（Y10K解決策の構造）

> Any Y10K solution should have the following characteristics.

Y10Kの解決策は、以下のような特徴を持つことが望ましい。

### 2.1 Compatibility（互換性）

> The format must be compatible with existing 4-digit date formats.
> Y2K compliant programs and standards must continue to work with Y10K dates before the year 10,000.
> Y10K compliant programs can gradually be developed over time and coexist with non-Y10K compliant programs.

そのフォーマットは、既存の 4 桁の日付フォーマットと互換性がなければならない。
Y2Kに準拠したプログラムと標準は、1万年前のY10Kの日付でも引き続き動作しなければならない。
Y10Kに準拠したプログラムは、時間をかけて徐々に開発し、Y10Kに準拠していないプログラムと共存させることができる。

### 2.2 Simplicity and Efficiency（シンプルで効率的）

> Y10K dates must allow dates after 10,000 to be easily identified.
> Within a program, there must be a simple procedure for recognizing the Y10K dates and distinguishing them from legacy dates.

Y10Kの日付は、10,000年以降の日付を容易に識別できるようにしなければならない。
プログラム内では、Y10Kの日付を認識し、レガシーの日付と区別するための簡単な手順が必要である。

### 2.3 Lexical Sorting（辞書的ソート）

> Y10K dates must be sortable lexically based on their ASCII representation.
> The dates must not require specialized libraries or procedures.

Y10Kの日付は、ASCII表現に基づき辞書的にソート可能でなければならない。
その日付は、特別なライブラリや手順を必要としないものでなければならない。

### 2.4 Future Extensibility（将来の拡張性）

> Y10K dates must support arbitrary precision dates, and should support dates extending arbitrarily far into the future and past.
> Y10K dates from different eras and with different precisions must be directly comparable and sortable.

Y10Kの日付は、任意の精度の日付をサポートする必要があり、また任意の未来や過去に及ぶ日付をサポートする必要がある。
異なる時代、異なる精度の Y10K 日付は、直接比較でき、ソート可能でなければならない。

#### 2.4.1 Environmental Considerations（環境に関する考慮）

> The known universe has a finite past and future.
> The current age of the universe is estimated in [Zebu] as between 10 \*\* 10 and 2 * 10 \*\*10 years.
> The death of the universe is estimated in [Nigel] to occur in 10 \*\* 11 - years and in [Drake] as occurring either in 10 \*\* 12 years for a closed universe (the big crunch) or 10 \*\* 14 years for an open universe (the heat death of the universe).
>
> In any case, the prevailing belief is that the life of the universe (and thus the range of possible dates) is finite.

既知の宇宙には、有限の過去と未来がある。
現在の宇宙の年齢は、[Zebu] では $10^{10}$年から$2 \times 10^{10}$年の間と推定されている。
宇宙の死は [Nigel] では$10^{11}$年から、[Drake] の閉じた宇宙では$10^{12}$年（ビッグクランチ）、開いた宇宙では$10^{14}$年（宇宙の熱死）で起こると推定されている。

いずれにせよ、宇宙の寿命（したがって、可能な日付の範囲）は有限であるというのが一般的な考えである。

#### 2.4.2 Transcending Environmental Considerations（環境に関する考慮を超えて）

> However, we might get lucky.
> So, Y10K dates are able to represent any possible time without any limits to their range either in the past or future.
>
> Y10K compliant programs MAY choose to limit the range of dates they support to those consistent with the expected life of the universe.
> Y10K compliant systems MUST accept Y10K dates from 10 \*\* 12 years in the past to 10 \*\* 20 years into the future.
> Y10K compliant systems SHOULD accept dates for at least 10 \*\* 29 years in the past and future.

しかし、我々は幸運に恵まれるかもしれない。
したがって、Y10Kの日付は、過去でも未来でも、その範囲に制限を加えることなく、あらゆる可能な時間を表現することができる。

Y10K準拠のプログラムは、サポートする日付の範囲を宇宙の予想寿命と一致する範囲に制限することを選択してもよい(MAY)。
Y10K準拠のシステムは、過去$10^{12}$年から未来$10^{20}$年までのY10K日付を受け入れなければならない(MUST)。
Y10K準拠のシステムは、少なくとも過去と未来、$10^{29}$年の日付を受け付けるべきである(SHOULD)。

## 3 Syntax Overview（文法の概観）

> The syntax of Y10K dates consists of simple, printable ASCII characters.
> The syntax and the characters are chosen to support a simple lexical sort order for dates represented in Y10K format.
> All Y10K dates MUST conform to these rules.
>
> Every Y10K date MUST begin with a Y10K year.
> Following the year, there MAY be an arbitrary sequence of digits.
> The digits are interpreted as MMDDHHMMSSmmmuuunnnpppfff...
> (month, day, hour, minute, second, milli-second, micro-second, nano-second pico-second, femto-second, etc. - moving left to right in the date, digits always decrease in significance).
>
> All dates and times MUST be relative to International Atomic Time (TAI) [NRAO].
>
> When comparing dates, a date precedes every other date for which it is a prefix.
> So, the date "19990401000000" precedes the date "19990401000000000".
> In particular, dates with the format YYYYMMDD are interpreted to represent the exact instant that the day begins and precede any other date contained in that day.

Y10Kの日付の構文は、単純で印刷可能なASCII文字で構成されている。
この構文と文字は、Y10K 形式で表現される日付の簡単な辞書的ソート順をサポートするために選択されている。
すべてのY10Kの日付は、以下の規則に従わなければならない(MUST)。

すべてのY10Kの日付は、Y10Kの年で始まらなければならない(MUST)。
年の後に、任意の数字が続いてもよい(MAY)。
数字は `MMDDHHMMSSmmmuuunnnpppfff...` として解釈される。
(月、日、時、分、秒、ミリ秒、マイクロ秒、ナノ秒、ピコ秒、フェムト秒、など —— 日付の左から右に行くほど、数字は常に小さくなる)。

すべての日付と時刻は、国際原子時（TAI）[NRAO]を基準としていなければならない(MUST)。

日付を比較する場合、日付はそれが接頭辞である他のすべての日付より前になる。
つまり、`19990401000000` という日付は `19990401000000000` という日付より前になる。
特に、`YYYYMMDD` という形式の日付は、その日が始まる瞬間を正確に表していると解釈され、その日に含まれる他のどの日時よりも優先される。

### 3.1 Years 1 - 9999（西暦1～9999年）

> The current 4-digit year syntax covers all years from 1000 - 9999.
> These years are represented as 4 decimal digits.
> Leading 0's MUST be added to the years before 1000 to bring the year to 4 digits.
> Files containing legacy pre-Y1K [Mike] dates will have to be converted.

現在の4桁の年号構文は、1000年から9999年までのすべての年号をカバーしている。
これらの年は10進数で4桁で表される。
1000年以前の年号は、4桁にするために先頭へ0を付けなければならない(MUST)。
Y1K [Mike] 以前の古い日付を含むファイルは、変換する必要がある。

### 3.2 Years 10,000 through 99,999（西暦10,000～99,999年）

> Four digits are not sufficient to represent dates beyond the year 9999.
> So, all years from 10,000 - 99,999 are represented by 5 digits preceded by the letter 'A'.
> So, 10,000 becomes "A10000" and 99,999 becomes "A99999".
> Since 'A' follows '9' in the ASCII ordering, all dates with 5-digit years will follow all dates with 4-digit years (for example, "A10000" will sort after "9999").
> This gives us the sort and comparison behaviour we want.

9999年を超える日付を表すには、4桁では不十分である。
そこで、10,000年から99,999年までのすべての年は、5桁の数字の先頭に`A`を付与して表す。
つまり、10,000年は`A10000`、99,999年は`A99999`となる。
ASCIIの並び順では、`A`は`9`の後に続くので、5桁の年号を持つすべての日付は4桁の年号を持つすべての日付に続くことになる（例えば、`A10000`は`9999`の後にソートされる）。
これによって、我々が望むソートと比較動作が得られる。

### 3.3 Years 100,000 up to 10 \*\* 30（西暦100,000～10の30乗 年）

> By a simple generalization of 3.2, 6-digit years are preceded by the letter 'B', 7-digit years by 'C', etc.
> Using just the 26 upper-case ASCII characters, we can cover all years up to 10\*\*30 (the last year representable is "Z999999999999999999999999999999").
> Again, since the ASCII characters are sorted alphabetically, all dates sort appropriately.

3.2節の単純な一般化により、6桁の年の前には`B`、7桁の年の前には`C`などの文字がつく。
ASCIIの大文字26文字だけで、$10^{30}$年までのすべての年をカバーできる（表現できる最後の年は `Z999999999999999999999999999999`）。
この場合も、ASCII文字はアルファベット順にソートされるため、すべての日付が適切にソートされる。

### 3.4 Years 10 \*\* 30 and beyond (Y10\*\*30)（10の30乗 年を超えて(Y10\*\*30)）

> As discussed in 2.4.1, the end of the universe is predicted to occur well before the year 10 \*\* 30.
> However, if there is one single lesson to be learned from the current Y2K problems, it is that specifications and conventions have a way of out living their expected environment.
> Therefore we feel it is imperative to completely solve the date representation problem once and for all.

2.4.1項で述べたように、宇宙の終わりは$10^{30}$年よりかなり前に起こると予測されている。
しかし、今回のY2K問題から学ぶべきことがあるとすれば、それは、仕様や規約は、想定された環境を生き抜くことができる、ということである。
したがって、日付表現の問題を完全に解決することが急務であると考える。

#### 3.4.1 Naive Approach for Y10\*\*30 Problem（Y10\*\*30問題に対するナイーブ取り組み）

> The naive solution is to prepend a single '^' (caret) - caret sorts after all letters in the ASCII order) before all years from 10 \*\* 30 to 10 \*\* 56.
> Thus the year "Z999999999999999999999999999999" is followed by the year "^A1000000000000000000000000000000".
> Similarly, all years from 10 \*\* 56 to 10 \*\* 82 get one more caret.
> So, the year "^Z99999999999999999999999999999999999999999999999999999999" is followed by the year "^^A100000000000000000000000000000000000000000000000000000000".
> This scheme can be extended indefinitely by prepending one addition caret for each additional factor of 10 \*\* 26 in the range of the year.
>
> In this approach, the number of digits in a date that are used to represent the year is simply:
>
>  26 * \<number of '^'> + ASCII(\<prefix letter>) - ASCII('A') + 5
>
> Note: this algorithm is provided for informational purposes only and to show the path leading to the true solution.
> Y10K dates MUST NOT use this format.
> They MUST use the format in the next section.

ナイーブな（訳注：未成熟な、拙い）解決策は、$10^{30}$ ～ $10^{56}$ 年までのすべての年号の前に一つの `^` (キャレット)を付けることである —— キャレットはASCII順ですべての文字の後にソートされる) を付けることである。
したがって、`Z999999999999999999999999999999` という年の後には、`^A1000000000000000000000000000000` という年が続くことになる。
同様に、$10^{56}$から$10^{82}$年までのすべての年は、キャレットが1つ多くなる。
つまり、`^Z99999999999999999999999999999999999999999999999999999999` の後に `^^A100000000000000000000000000000000000000000000000000000000` という年号が続くことになる。
この方式は、年の範囲に$10^{26}$の係数が追加されるごとに1つの加算キャレットを前置することで無限に拡張することができる。

この方式では、年を表すために使われる日付の桁数は、単純に以下のようになる：

```
    26 * <'^'の数> + ASCII(<プレフィックス文字>) - ASCII('A') + 5
```

注：このアルゴリズムは、情報提供のみを目的とし、真の解に至る道筋を示すために提供されている。
Y10Kの日付はこの形式を使用してはならない(MUST NOT)。
次項のフォーマットを使用しなければならない(MUST)。

#### 3.4.2 Space Efficient Approach for Y10\*\*30 Problem（Y10\*\*30問題に対する空間効率的なアプローチ）

> The solution in 3.4.1 is not a space efficient format for giving the number of digits in the year.
> The length of the prefix grows linearly in the length of the year (which, itself, grows logarithmically over time).
> Therefore, Y10K format dates use an improved, more compact encoding of the number of digits in the year.

3.4.1項の解決策は、年の桁数を示すための空間効率のよい形式ではない。
接頭辞の長さは年の長さに対して直線的に増加する (それ自体、時間の経過とともに対数的に増加する)。
したがって、Y10K形式の日付は、年の桁数をよりコンパクトにするために改良された符号化方式を使用する。

##### 3.4.2.1 Years 10 \*\* 30 to 10 \*\* 56（西暦 10の30乗 ～ 10の56乗 年）

> As in 3.4.1, a single '^' and letter precede the year.

3.4.1項と同様、年の前に`^`と文字が1つずつ入る。

##### 3.4.2.2 Years 10 \*\* 56 to 10 \*\* 732（西暦 10の56乗 ～ 10の732乗 年）

> The year is preceded by two carets ("^^") and two letters.
> The letters create a two digit, base 26 number which is the number of digits in the year minus 57.
> So, the year "^Z99999999999999999999999999999999999999999999999999999999" is followed by the year "^^AA100000000000000000000000000000000000000000000000000000000".
> The last representable year with two carets is the year (10 \*\* 732) - 1 and is "^^ZZ999..999" (i.e. two carets and two Z's, followed by 732 consecutive 9's).
>
> The formula for the number of digits in the year is, based on the two digit prefix is:
>
> ```
>    26 * (ASCII(\<prefix letter1>) - ASCII('A')) +
>          ASCII(\<prefix letter2>) - ASCII('A') + 57
> ```

年の前には2つのキャレット(`^^`)と2つの文字が入る。
この文字によって、年号の桁数から$57$を引いた、2桁の26進数(訳注：A～Zの26文字を使った26進数)の数字が作られる。
つまり、`^Z99999999999999999999999999999999999999999999999999999999` の後に `^^AA100000000000000000000000000000000000000000000000000000000` という年号が続くわけである。
キャレットが2つある最後の表現可能な年は、$10^{732} - 1$で、`^^ZZ999..999`（つまり、キャレット2つとZが2つ、そして9が732個連続）である。

年の桁数の計算式は、2桁のプレフィックスをもとに、次のようになる。

```
    26 * (ASCII(<プレフィックス文字1>) - ASCII('A')) +
          ASCII(<プレフィックス文字2>) - ASCII('A') + 57
```

##### 3.4.2.3 Years 10 \*\* 732 to 10 \*\* 18308（西暦 10の732乗 ～ 10の18308乗 年）

> The next block of years has the number of digits given by three carets ("^^^") followed by three letters forming a three-digit, base 26 number.
> The number of digits in the year is given by the formula:
>
> ```
>    676 * (ASCII(<prefix letter1>) - ASCII('A')) +
>     26 * (ASCII(<prefix letter2>) - ASCII('A')) +
>           ASCII(<prefix letter3>) - ASCII('A') + 733
> ```

次のブロックの年は、3つのキャレット（`^^^`）の後に3つの文字が続き、3桁の26進数を形成することで桁数が与えられる。
年号の桁数は式で与えられる。

```
    676 * (ASCII(<プレフィックス文字1>) - ASCII('A')) +
     26 * (ASCII(<プレフィックス文字2>) - ASCII('A')) +
           ASCII(<プレフィックス文字3>) - ASCII('A') + 733
```

##### 3.4.2.4 General Format for Y10K Dates（Y10K日付の一般的なフォーマット）

> In general, if there is at least one letter in a Y10K year, the number of the digits in the year portion of the date is given by the formula:
>
> ```
>     base26(fib(n) letters) + y10k(n)
> ```
>
> Where "n" is the number of leading carets and the fib, base26 and y10k functions are defined with the following recurrence relations:
>
> fib(n) is the standard Fibonacci sequence with:
>
> ```
>     fib(0) = 1
>
>     fib(1) = 1
>
>     fib(n+2) = fib(n) + fib(n+1)
> ```
>
> base26(m letters) is the base 26 number represented by m letters A-Z:
>
> ```
>     base26(letter) =  ASCII(<letter>) - ASCII('A')
>     base26(string letter) = 26 * base26(string) + base26(letter)
>
> ```
>
> y10k(n) is the necessary fudge factor to align the sequences properly:
>
> ```
>     y10k(0) = 5
>     y10k(n+1) = 26 \*\* fib(n) + y10k(n)
> ```
>
> If the year does not have at least one letter in the year, then the number of digits in the year is:
>
> ```
>     4
> ```
>
> This year format is space-efficient.
> The length of the prefix giving number of digits in the year only grows logarithmically with the number of digits in the year.
> And, the number of carets preceding the prefix only grows logarithmically with the number of digits in the prefix.

一般に、Y10Kの年号に少なくとも1文字があれば、日付の年号部分の桁数は次の式で与えられる。

```
    base26(fib(n)文字) + y10k(n)
```

ここで、n は先頭のキャレットの数であり、fib, base26, y10k関数は以下の漸化式で定義されている。

fib(n) は標準的なフィボナッチ数列で、次のようになる：

```
    fib(0) = 1

    fib(1) = 1

    fib(n+2) = fib(n) + fib(n+1).
```

base26(m 文字) は、m 個の `A`-`Z` の文字で表される26進数の数である。

```
    base26(文字) = ASCII(<文字>) - ASCII('A')
    base26(文字列 文字) = 26 * base26(文字列) + base26(文字)
```

y10k(n) はソート順を適切に配置するために必要なファジーファクターである。

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

年号に1文字以上含まれない場合、年号の桁数は

```
    4
```

この年号の形式はスペース効率が良い。
年の桁数を示すプリフィックスの長さは、年の桁数に対して対数的に大きくなるだけである。
また、プリフィックスの前のキャレットの数は、接頭辞の桁数に対して対数的にしか増加しない。

### 3.5 B.C.E. (Before Common Era) Years（紀元前）

> Now that have a format for all of the years in the future, we'll take on the "negative" years.
> A negative year is represented in "Y10K-complement" form.
> A Y10K-complement year is computed as follows:
>
> 1. Calculate the non-negative Y10K year string as in 3.4.2.4.
> 2. Replace all letters by their base 26 complement.  I.E. A -> Z, B -> Y, ... Z -> A.
> 3. Replace all digits in the year portion of the date by their base 10 complement.  I.E. 0 -> 9, 1 -> 8, ... 9 -> 0.
> 4. Replace carets by exclamation points ('!').
> 5. Four-digit years are pre-pended with a slash ('/')
> 6. Years that don't now begin with an exclamation point or slash are pre-pended with a star ('*').  (This rule covers the negative 5-31 digit years).
>
> For example, the year 1 BCE is represented by "/9998".
> The conversion is accomplished by applying rules:
>
> 1. Calculate the non-negative Y10K year ("1" -> "0001")
> 2. Complement the digits ("0001" -> "9998")
> 3. Four-digit numbers get a leading slash.
>
> The earliest four-digit BCE year (9999 BCE) becomes "/0000" and the year before that (10000 BCE) becomes "*Z89999".
> The earliest 5-digit BCE year (99999 BCE) is "*Z00000".
> And the year before that (100000 BCE) is "*Y899999".
> And so on.
>
> These rules give the desired sort order for BCE dates.
> For example, the following dates get translated and sorted as:
>
> ```
>      Jun 6, 200 BCE            /97990606
>      199 BCE                   /9800
>      Jan 1, 199 BCE            /98000101
> ```

さて、未来のすべての年号のフォーマットが決まったところで、「マイナス」年を取り上げる。
負の年は「Y10Kの補数」という形で表現される。

https://ja.wikipedia.org/wiki/%E8%A3%9C%E6%95%B0

Y10Kの補数の年は次のように計算される。

1. 3.4.2.4 のように、非負のY10K年文字列を計算する。
2. すべての文字をその26進数の補数で置き換える。 すなわち、`A`→`Z`、`B`→`Y`、……、`Z`→`A`。
3. 日付の年号部分のすべての数字を、10の補数で置き換える。 すなわち、`0`→`9`、`1`→`8`、……、`9`→`0`。
4. キャレットを感嘆符(`!`)に置き換える。
5. 4桁の年は、スラッシュ(`/`)を前置する。
6. 感嘆符やスラッシュで始まらない年は、星印(`*`)を先頭に付ける(このルールは、マイナス5桁から31桁の年号を対象としている)。

例えば、紀元前1年は「/9998」で表される。
この変換は以下のルールを適用することで実現される：

1. 負でないY10K年を計算する(`1`→`0001`)
2. 桁の補数を求める (`0001`→`9998`)
3. 4桁の数字には先頭にスラッシュを付ける。

4桁の紀元前9999年は`/0000`、その前の紀元前10000年は`*Z899999`となる。
最も古い紀元前5桁の年（紀元前99999年）は `*Z00000` となる。
そして、その前の年（紀元前100000年）は`*Y899999`である
といった具合である。

これらの規則により、紀元前の日付の望ましいソート順が得られる。
例えば、次のような日付が変換され、ソートされる：

```
     紀元前200年6月6日 /97990606
     紀元前199年       /9800
     紀元前199年1月1日 /98000101
```
### 3.6 Restrictions on Y10K Dates（Y10K日付の制限）

> There are no restrictions on legal values for Y10K dates.
> Y10K compliant programs MUST accept any syntactically legal Y10K date as a valid date.
> A '0' can be appended to the end of any Y10K date, yielding an equivalent date that sorts immediately after the original date and represents the instant after the original date.
>
> The following are all valid representations (in sorted order) of the first instant of A10000:

Y10Kの日付には、有効な値に関する制限はない。
Y10K準拠のプログラムでは、構文的に有効なY10K日付はすべて有効な日付として受け入れなければならない(MUST)。
Y10Kの日付の末尾に`0`を追加すると、元の日付の直後にソートされ、元の日付の次の瞬間を表す同等の日付が得られる。

以下は、`A10000` の最初の瞬間の有効な表現(ソート順)である：

```
     A1
     A10000
     A1000001
     A100000101000000
     A1000001010000000000000000000000
```

> Similarly, the following are all valid Y10K dates (in sorted order) for the time after the last instant of the A99999 and before the first instant of B100000:

同様に、`A99999`の最後の瞬間の後、`B100000`の最初の瞬間の前の時間に対して有効なY10Kの日付（ソート順）は以下の通りである：

```
     A999991231250000
     A999991232
     A999992
     A9999999999
     A99999999990000000000000
```

## 4 ABNF

> The following ABNF [Crocker] gives the formal syntax for Y10K years.
>
> The initial characters definitions are given in their lexical collation (ASCII) order.

以下の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 Open Issues（未解決の問題）

> There are a number date comparison problems that are beyond the scope of this specification.
>
> 1. Dates from different calendar systems can not be directly compared.  For instance, dates from the Aztec, Bhuddist, Jewish, Muslim, and Hittite calendars must be converted to a common calendar before comparisons are possible.
>
> 2. Future re-numberings of years are not covered.  If, and when, a new "Year 0" occurs and comes into general use, old dates will have to be adjusted.
>
> 3. Continued existence of Earth-centric time periods (year, day, etc.) are problematical past the up-coming destruction of the solar system (5-10 billion years or so).  The use of atomic-time helps some since leap seconds are no longer an issue.
>
> 4. Future standards and methods of synchronization for inter-planetary and inter-galactic time have not been agreed to.
>
> 5. Survivability of dates past the end of the universe is uncertain.

この仕様の範囲を超えて、多くの日付の比較問題がある。

1. 異なる暦法による日付は直接比較できない。 例えば、アステカ暦、ブディスト暦、ユダヤ暦、イスラム暦、ヒッタイト暦の日付は、比較する前に共通のカレンダーに変換する必要がある。

2. 将来の改暦は対象外である。 将来的に「0年」が一般に使用されるようになった場合、古い日付を調整する必要がある。

3. 来るべき太陽系の滅亡（50～100億年程度）を経た際、地球を中心とした時間軸（年、日など）の存続の問題がある。 原子時間の使用により、うるう秒の問題がなくなるので、ある程度は解決するだろう。

4. 惑星間、銀河間の時刻の同期について、今後の基準や方法について合意が得られていない。

5. 宇宙の終焉を過ぎた日付の存続が不確かである。

## 6 Affected Standards（影響を受ける標準）

> A number of standards currently and RFCs use 4-digit years and are affected by this proposal:

現在、多くの標準とRFCは4桁の年を使用しており、この提案の影響を受ける：

```
     rfc2459: Internet X.509 Public Key Infrastructure
              Certificate and CRL Profile
     rfc2326: Real Time Streaming Protocol (RTSP)
     rfc2311: ODETTE File Transfer Protocol
     rfc2280: Routing Policy Specification Language (RPSL)
     rfc2259: Simple Nomenclator Query Protocol (SNQP)
     rfc2244: ACAP -- Application Configuration Access Protocol
     rfc2167: Referral Whois (RWhois) Protocol V1.5
     rfc2065: Domain Name System Security Extensions
     rfc2060: Internet Message Access Protocol - Version 4rev1
     rfc1922: Chinese Character Encoding for Internet Messages
     rfc1912: Common DNS Operational and Configuration Errors
     rfc1903: Textual Conventions for Version 2 of the
              Simple Network Management Protocol (SNMPv2)
     rfc1521: MIME (Multipurpose Internet Mail Extensions) Part One:

     rfc1123: Requirements for Internet hosts - application and support
```

> The following standards internally represent years as 16-bit numbers (0..65536) and are affected by this proposal:

次の標準は、内部的に年を16ビット数（0～65536）として表し、この提案の影響を受ける。
（訳注：0～65535の間違い？ 正誤表には載っていない）

```
     rfc2021: Remote Network Monitoring Management Information Base
              Version 2 using SMIv2
     rfc1514: Host Resources MIB
```

> The following ISO standard is affected:

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

```
     ISO8601: International Date Format
```

## 8 Security Considerations（セキュリティに関する考慮事項）

> Y10K dates will improve the security of all programs where they are used.
> Many errors in programs have been tracked to overflow while parsing illegal input.
> Programs allocating fixed size storage for dates will exhibit errors when presented with larger dates.
> These errors can be exploited by wily hackers to compromise the security of systems running these programs.
> Since Y10K dates are arbitrary length strings, there is no way to make them overflow.
>
> In addition, positive Y10K dates are easy to compare and less error-prone for humans.
> It is easier to compare the three projected end of the universe dates - "H100000000000", "I1000000000000" and "K100000000000000" - by looking at the leading letter than by counting the 0's.
> This will reduce inadvertent errors by people.
> This advantage will become more noticeable when large dates are more common.
>
> Unfortunately, negative Y10K dates are a bit more difficult to decipher.
> However, by comparing the current age of the universe to its projected end, it is obvious that there will be many more positive dates than negative dates.
> And, while the number of negative dates for human history is currently greater than the number of positive dates, the number of negative dates is fixed and the number of positive dates is unbounded.

Y10K日付は、それらが使用されるすべてのプログラムのセキュリティを向上させる。
プログラムの多くのエラーは、不正な入力の解析中のオーバーフローである。
日付に固定サイズのストレージを割り当てるプログラムでは、日付が大きい場合にエラーが発生する。
これらのエラーは、これらのプログラムを実行しているシステムのセキュリティを危険にさらすために、巧妙なハッカーによって悪用される可能性がある。
Y10K日付は任意の長さの文字列であるため、オーバーフローさせる方法はありません。

さらに、正のY10K日付は比較が容易で、人間にとってエラーが発生しにくいものである。
0を数えるよりも先頭の文字を見る方が、宇宙の3つの予測される終わりの日付（`H100000000000`、`I1000000000000`、`K100000000000000`）を比較するのが簡単です。
これにより、人による不注意によるエラーが減ることになる。
この利点は、大きな日付が一般的である場合にさらに顕著になる。

残念ながら、負のY10K日付は、解読が少し難しくなる。
しかし、宇宙の現在の年齢をその予測された終わりと比較することによって、負の日付よりもはるかに多くの正の日付があることは明らかである。
そして、人類の歴史の負の日付の数は現在、正の日付の数よりも多いが、負の日付の数は固定されており、正の日付の数は無制限である。

## 9 Conclusion（結論）

> It is not too early to aggressively pursue solutions for the Y10K problem.
> This specification presents a simple, elegant, and efficient solution to this problem.

Y10K問題の解決策を積極的に追求するのは時期尚早ではない。
この仕様書は、この問題に対するシンプルでエレガントかつ効率的なソリューションを提供する。

## 10 References

```
   [Crocker]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, November 1997.

   [Drake]     Review for the Drake Equation
               http://www.umsl.edu/~bwilking/assign/drake.html

   [Microsoft] SNMP SysUpTime Counter Resets After 49.7 Days
               http://support.microsoft.com/support/kb/articles/Q169/
               8/47.asp

   [Mike]      Y1K http://lonestar.texas.net/~mdlvas/y1k.htm

   [Nigel]     Nigel's (en)lighening tour of Thermodynamics for
               Economists ;-) http://www.santafe.edu/~nigel/thermo-
               primer.html

   [NRAO]      Astronomical Times
               http://sadira.gb.nrao.edu/~rfisher/Ephemerides/times.html

   [RFC]       Here are all the online RFCs. Note: this is a LONG menu.
               http://info.internet.isi.edu/1s/in-notes/rfc/files

   [UNIX]      Year 2000 Issues http://www.rdrop.com/users/caf/y2k.html

   [Wilborne]  PktCDateLig
               http://www3.gamewood.net/mew3/pilot/pocketc/pktcdate/
               index.html

   [YUCK]      Y10K Unlimited Consulting Knowledgebase
               http://www.loyd.net/y10k/index.html

   [Zebu]      The Search for H0
               http://zebu.uoregon.edu/1997/ph410/l6.html
```

## 11 Authors' Addresses

```
   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.  Full Copyright Statement

```
   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.
```