閏年の問題

閏年問題（うるう年バグまたは閏日バグとも呼ばれる）は、デジタル（コンピュータ関連）および非デジタルの両方の文書およびデータ保存状況で発生する問題であり、どの年が閏年であるかを計算する際のエラー、または閏年と平年の違いを考慮せずに日付を操作することから生じます。

閏年バグは、実世界での使用に与える影響の大きさに基づいて、通常2つのカテゴリに分類されます。^[1]

1. 例外、エラー戻りコード、初期化されていない変数、無限ループなど、エラー状態につながるもの
2. 範囲クエリや集計における1つずれの問題など、不正確なデータにつながるもの

次の Python コードは、カテゴリ 1 の閏年バグの例です。2today月 29 日になるまでは正常に動作します。その後、存在しない平年の 2 月 29 日を作成しようとします。コンストラクタは、"日が月の範囲外です" というメッセージとともにdateエラーを発生させます。 ^[2]ValueError

 datetime からdateをインポートし ます。today = date .today ( ) later = today .replace ( year = today .year + 1 )
  
      

次の Windows C++ コードは、カテゴリー 1 のうるう年のバグの例です。現在の日付がうるう年の 2 月 29 日になるまでは正常に動作します。その後、st実際には存在しない平年の 2 月 29 日を表すように変更されます。構造体をパラメーターとして st受け入れる関数に渡すと、失敗する可能性があります。SYSTEMTIME

たとえば、SystemTimeToFileTimeここに示す呼び出しはエラーコードを返します。その戻り値はチェックされていないため（これは非常に一般的です）、ft初期化されていないままになります。^[3]

システム時間st ;ファイル時間ft ; 
 

GetSystemTime ( & st ); 
st . wYear ++ ;

SystemTimeToFileTime ( & st 、& ft ); 

次の .NET C# コードは、カテゴリー 1 の閏年バグの例です。2dt月 29 日になるまでは正常に動作します。その後、存在しない平年の 2 月 29 日を作成しようとします。DateTimeコンストラクタは例外をスローしますArgumentOutOfRangeException。^[4]

DateTime dt = DateTime.Now ; DateTime result = new DateTime ( dt.Year + 1 , dt.Month , dt.Day ) ;​​​​​​​   
        

次の JavaScript コードは、カテゴリー 2 のうるう年のバグの例です。2020-02-29dtなどの 2 月 29 日までは正常に動作します。その後、年を 2021 年に設定しようとします。2021-02-29 は存在しないため、Dateオブジェクトは次の有効な日付である 2021-03-01 にロールフォワードされます。^[5]

var dt = new Date ( ) ; dt.setFullYear ( dt.getFullYear ( ) + 1 ) ;    
  

次のコードは、多くの言語で見られるうるう年のバグの例です。結果が何に使用されるかによって、カテゴリ 1 またはカテゴリ 2 の影響が発生する可能性があります。うるう年は正確に 4 年に 1 回発生すると誤って想定しています。^[6]

bool isLeapYear =年% 4 == 0 ;       

正しい閏年アルゴリズムについては、閏年アルゴリズム^{[リンク切れ‍ ]}で説明されています。

• Microsoft Excelは、その初期のバージョンから、1900 年を誤って閏年とみなしていたため、2 月 29 日はその年の 2 月 28 日から 3 月 1 日の間に来ていました。このバグはLotus 1-2-3に由来し、下位互換性のために Excel に意図的に実装されました。Microsoft はこのバグについて記事を書き、1900 年を閏年として扱う理由を説明しています。^[7]このバグは、Ecma Office Open XML (OOXML) 仕様の要件に昇格されました。^{[8] [9]}
• 1996年12月31日、ニュージーランドのティワイポイントとオーストラリアのタスマニア島ベルベイにある2つのアルミニウム製錬工場で、製錬ポットラインを制御する660台のコンピューターが、1年の366日目を処理するようにプログラムされていなかったため、真夜中にシャットダウンしました。修理費用は100万ニュージーランドドル以上と見積もられました。^[10]
• 2000年12月31日、ノルウェーの国営鉄道会社Vyは、車載コンピューターが日付を1年の366日目として認識しなかったため、新しいSignatur列車29両すべてが運行不能になったことを発見した。暫定措置として、技術者は時計を1か月戻して列車を再開した。^{[11] [12] [13]}
• 2008年12月31日の深夜、多くの^[14]第1世代Zune 30モデルがフリーズした。^{[15] [16]マイクロソフトは、この問題は}フリースケールが作成した内部クロックドライバと、デバイスがうるう年を処理する方法によって引き起こされたと述べた。問題は24時間後に自動的に修正されたが、待ちたくない人のための中間的な「修正」は、デバイスのバッテリーを使い切ってから、2009年1月1日の正午（UTC）以降に再充電することだった。 ^{[17] [18]}
• ソニーのプレイステーション3は2010年を誤って閏年として扱ったため、存在しない2010年2月29日が2010年3月1日として表示され、プログラムエラーが発生した。^[19]
• 2012年、トムトムの衛星ナビゲーションデバイスは、3月31日に初めて発生したうるう年のバグにより故障した。^[20]
• 2012年、Gmailのチャット履歴には、 2月29日に保存されたすべてのチャットの日付が1969年12月31日と表示されていました。^{[引用が必要]}
• 2012 年 2 月 28 日、Microsoft Azure はうるう年のバグによりオフラインになり、仮想マシンの起動時にクラッシュしました。午後 5 時 45 分 (太平洋標準時) に Windows Azure チームは問題に気付きましたが、最終的には、年を変更しながら日を変更しない「1 年後」の操作が原因であることが判明しました。
• 2016年には、 Code of Mattのウェブサイトの「2016年閏日バグのリスト」に多数の閏年バグが掲載されました。^[21]
• 2016年2月29日、デュッセルドルフ空港の荷物搬送システムに閏年バグが発生し、1,200個以上の荷物がフライトに乗り遅れた。^[22]
• 2020年には、 Code of Mattのウェブサイトの「2020年閏日バグのリスト」に多数の閏年バグが掲載されました。^[23]
• 2024年には、 Code of Mattのウェブサイトの「2024年閏日バグのリスト」に多数の閏年バグが掲載されました。^[24]
• 2024年には、うるう年のバグにより、ニュージーランドの自動支払い式給油所が10時間以上オフラインになった。^[25]

• 時刻のフォーマットと保存に関するバグ
• 2100年問題