>>716
実は割とよく起きてる問題である
1999年問題 - 1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。
また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、
そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。
又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
1999年8月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。
2000年問題（Y2K） - 年数を下2桁だけで処理していたシステムや、2000年を平年（閏年ではない）と誤解したシステムに問題が起こる。
2001年9月9日問題 - 1970年1月1日0時からの秒数が十進法で9桁から10桁になる。
経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、
項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
2004年1月10日問題 - 2038年問題の派生形で、1970年1月1日0時（Unix epoch）から
2038年1月19日までの約21億秒の中間点にあたるこの日に潜在的なバグが発覚した。
KDDIの通話料金処理、IIJのSEIL/neuルーター、20行以上の日本国内銀行ATMで、同日または翌日以降にトラブルが発生した。
CADソフト「Pro/ENGINEER」は1ヶ月前に誤動作の可能性を発見し予め対処してトラブルを回避した。[1]
2008年問題 - 2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、
先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。
ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
2010年問題 - 潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」（閏年処理）、
オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。
シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
2019年4月7日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。
（10ビットでは2回目）
2020年問題 - 2000年問題の1920年起点版。UNIXエポックの1970年1月1日±50年である
1920 - 2019年をdate windowとしたシステムで誤動作を起こしている。
2036年2月7日問題 - 1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。
2038年1月19日問題 - いわゆる2038年問題。Unix等で、1970年1月1日0時（Unix epoch）からの秒数が31ビットからあふれ、
32ビット符号付きで処理しているシステムに問題が起こる。
ext2、ext3、ReiserFS、UFS1、XFS等の各ファイルシステムのタイムスタンプはこの日までしか扱えない。
2038年4月23日問題 - ユリウス通日を内部日付表現に用いる物のうち、
基準日（グレゴリオ歴1858年11月17日正午）からの修正ユリウス日（MJD）を使用し、
かつ16ビットで処理しているシステムでは、日数が16ビットからあふれるために問題が起こる。
2038年11月21日問題 - GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。
（10ビットでは3回目）
2040年問題 - MacOS等のファイルシステムHFSのタイムスタンプは2040年2月6日までしか取り扱えない。
2042年問題 - System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
2048年問題 - 2038年問題の1980年起点版。
2053年問題 - 2038年問題の1985年起点版。TRONなど。