時刻フォーマットとストレージのバグ

コンピュータサイエンスにおいて、データ型の制限やソフトウェアのバグは、時刻や日付の計算または表示にエラーを引き起こす可能性があります。これらは最も一般的な例として算術オーバーフローですが、他の問題が原因となる場合もあります。この種の問題で最もよく知られているのはY2K問題ですが、プログラミング上の様々な欠陥によって問題を引き起こした、あるいは今後引き起こすであろう、他にも多くの重要な日付や時刻が存在します。

1975年1月5日、DEC PDP-10コンピュータのTOPS-10オペレーティングシステム で日付に使用されていた12ビットフィールドがオーバーフローし、「DATE75」と呼ばれるバグが発生しました。このフィールドの値は、1964年1月1日からの年数に12を掛け、1月からの月数を加え、31を掛け、月の初めからの日数を加えることで計算されていました。符号なし12ビット整数で表現できる最大値は2¹² - ​​1 = 4095であり、4095は1975年1月4日を表し^ます。  ${\displaystyle (((11{\text{ years since 1964}})\times 12)+0{\text{ months since January}})\times 31)+3{\text{ days since start of the month}}=4095}$

したがって、 1975 年 1 月 4 日がエンコード可能な最新の日付です。「DATE-75」パッチは、ファイルシステムのメタデータの他のフィールドから 3 ビットの余剰を使用することで、エンコード可能な最後の日付を 2052 年 2 月 1 日まで押し上げ、オーバーフロー日付を 2052 年 2 月 2 日としましたが、これ により、これらのビットを独自の目的で使用するソフトウェアで問題が発生することがありました。一部のソフトウェアは日付に 1 ビットを追加で使用してサポートしていた可能性がありますが、追加ビットに問題があり、1986 年 1 月9 日にバグが発生した可能性があります。 ^{[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]} 

デジタル・イクイップメント・コーポレーションのPDP-8コンピュータ用OS/8オペレーティングシステムは、1970年からの年数を格納するために符号付き4ビットニブルを使用しており、これは1970年から1977年までの年しか表すことができませんでした。 ^{[ 5 ] [ 6 ]}

これはCOS-310オペレーティングシステムが開発された際に認識され、日付の記録方法が変更されました。^{[ 7 ]}

1993年9月18日、Classic Mac OS向けにリリースされた複数のSierra Entertainmentゲームが、実行中にフリーズするようになった。SierraのCreative Interpreter （Mac SCI）のMac版に問題があり、オーバーフローの問題により遅延処理を行おうとするとゲームが「ロックアップ」してしまう。Mac SCIは、1904年1月1日（Macintoshエポック）からの秒数で現在時刻を取得し、12時間で割ることで、遅延の長さを決定しようとしていた。この除算はMotorola 68000で処理され、除算によってオーバーフローが検出された場合は実行されなかったが、Mac SCIは除算が行われたかのように処理を続け、最終的に1秒の遅延が18時間の遅延として扱われる、といった事態が発生した。Sierraは、この問題を約14年間解決するMCDATEというパッチをリリースした。^{[ 8 ] [ 9 ]}     

アポロコンピュータのDomain/OSオペレーティングシステムでは、絶対時刻は1980年1月1日からの4マイクロ秒単位の数を表す符号付き48ビット整数として格納されていました。 この値は1997年11月2日にオーバーフローし 、パッチが適用されていないシステムは使用不能になりました。^{[ 5 ] [ 10 ]}

2000年を迎える前の数ヶ月間に、当時差し迫っていたY2K問題ほど注目を集めなかったものの、日付に関連する他の2つの重要な出来事があった。

Unix エポックからの秒数として9桁の数字列を使用して時間を記録するシステムでは、 2001年9月9日午前1時46分40秒（「ビレニアム」）のエポックから10億秒を超える時間を報告する 際に問題が発生しました。問題は広範囲に及んでいませんでした。^{[ 5 ] [ 14 ]}

MCDATE プログラムでパッチが適用された、またはパッチが組み込まれた状態で後からリリースされたClassic Mac OS用の Sierra Entertainment ゲームは、 2007 年 5 月 28 日にフリーズし始めました。1993年 問題と同様に、これは Mac SCI が日付を使用して遅延の長さを決定しようとしたときに発生した問題が原因でした。MCDATE パッチが適用されたプログラムは、Mac SCI がMacintosh エポックである 1904 年 1 月1 日からの現在の秒数を取得し、そこから 432,000,000 秒を減算し、Motorola 68000 を介して 12 時間で割って、遅延の長さを決定するため、フリーズします。2007 年 5 月 28 日、Motorola 68000 はオーバーフロー保護のために再び割り算を行いませんでしたが、Mac SCI はこれを無視しました。^{[ 8 ]}    

年が2010年になると、一部のシステムで問題が発生しました。これは一部のメディアで「Y2K+10」または「Y2.01k」問題と呼ばれました。^{[ 15 ]}

問題の主な原因は、16進数エンコーディングとBCDエンコーディングの混同でした。0から9までの数字は、16進数とBCDの両方で00 ₁₆から09 ₁₆とエンコードされます。しかし、10進数の10は、16進数では0A ₁₆、BCDでは10 ₁₆とエンコードされます。そのため、BCDの10 ₁₆を16進数エンコーディングとして解釈すると、誤って10進数の16を表してしまうのです。

例えば、SMSプロトコルは日付にBCDエンコーディングを使用するため、一部の携帯電話ソフトウェアはメッセージの日付を2010年ではなく2016年と誤って報告していました。Windows Mobileは、この不具合の影響を受けた最初のソフトウェアとして報告されました。場合によっては、WM6は2010年1月1日以降に送信された受信SMSメッセージの日付を 2010年から2016年に変更しました。 ^{[ 5 ] [ 16 ] [ 17 ]}

最も注目すべき不具合はドイツで発生し、2000万枚以上の銀行カードが使用できなくなり、また、シティバンク・ベルギーでは顧客識別チップが機能しなくなった。^{[ 18 ]}

影響を受けるその他のシステムには、 EFTPOS端末^{[ 19 ]} 、およびPlayStation 3（スリムモデルを除く）^{[ 20 ]が含まれます。}

ソニーのPlayStation 3は2010年を閏年と誤って認識したため、存在しない 2010年2月29日が2010年3月1日に表示され、プログラムエラー が発生した。^{[ 5 ] [ 21 ]}

台湾は公式には民国暦を使用しており、グレゴリオ暦の1912年を元年としています。したがって、グレゴリオ暦の2011年は中華民国暦100年であり、最初の3桁の年となります。^{[ 5 ] [ 22 ]}このため、2桁の表記を使用すると、年が1911年（元年0）のように見えます。

ディープインパクト探査機は、タイムタグの問題により、2013年8月11日に地球との通信を失いました。日付は、 2000年1月 1日からの10分の1秒数をカウントする符号なし32ビット整数として保存されていました。^{[ 23 ]} 

ビデオゲームのWWE 2K20とStar Wars Jedi: Fallen Orderは、2020年1月1日に年が明けた際に両方ともクラッシュしました。パッチがリリースされるまで、この不具合は年を2019年に戻すことでしか回避できませんでした。 ^{[ 24 ] [ 25 ]}さらに、Crystal Reports 8.5は2020年から特定のレポートを生成できなくなりました。^{[ 26 ]} 

ニューヨーク市やその他の場所にあるParkeon のパーキング メーターは、2020 年以降、クレジットカードでの支払いを受け付けることができなくなりました。回避策が実施されましたが、各メーターを個別に更新する必要がありました。ニューヨークでは、メーターの修理は 1 月 9 日まで行われない見込みでした。 ^{[ 27 ] [ 28 ]}

ポーランドでは、5000台のレジで日付が正しく印刷されなくなった。^{[ 29 ]}

Suuntoのスポーツスマートウォッチでは、曜日の計算にエラーがあり、実際の日付より2日先の日付が表示されていました（例：WEDではなくFRI、THUではなくSAT）。Suunto Spartanモデルの時計では、ファームウェアリリース2.8.32でこのバグが修正されました。^{[ 30 ]}

Samsungユーザーからは、One UI 3.0アップデートまたはAndroid 11を実行しているスマートフォンが2021年からバッテリーと充電の統計情報にアクセスできなくなったという報告があった。影響を受けたデバイスは使用統計を報告しないため、これらのセクションは空白のままになる。^{[ 34 ] [ 35 ]}

yymmddHHMM 形式で保存された日付を符号付き 32 ビット整数に変換したところ、 2 ³¹ = 2147483648 となるため、2022 年 1 月1 日にオーバーフローしました。特に影響を受けたのは、最新の更新を判断するための数学的チェックに使用されていると思われるMicrosoft Exchangeのマルウェア スキャン コンポーネントの更新番号です。^{[ 36 ] [ 37 ]}

2004年から2012年の間に製造されたホンダとアキュラの自動車で、 GPSナビゲーションシステムを搭載した車両に、年が誤って2002年と表示されるという問題が発生しました。この問題は、GPSエポックのオーバーフローが原因でした。^{[ 38 ] [ 39 ]}この問題は2022年8月17日に解決されました。^{[ 40 ]}

ニュージーランドのガソリンスタンドの決済カードリーダーはうるう年に対応できず、ガソリンを適切に給油できなかった。^{[ 41 ]}

EA Sports WRCとTheatrhythm Final Bar Lineの2つのビデオゲームもうるう年に関連した問題に見舞われ、前者はゲームをロードしようとしたときにクラッシュし、後者はセーブデータが破損していると表示されました。両方のゲームは 正常に動作するために、翌日の2024年3月1日に設定する必要がありました。^{[ 42 ] [ 43 ] [ 44 ]}

2024年12月、 HCL Notesの全バージョンで30年前のバグが発見されました。2024年12月13日以降にサーバーを起動すると 、オーバーフローによりメールルーターが構成をロードできず、メールが配信されません。翌日、サポートされているすべてのバージョン向けにパッチがリリースされました。^{[ 45 ]}

日本では、更新されていない古いコンピュータシステムの中には、依然として昭和元号で年を数えているものがある。そのようなシステムでは、2025年は昭和100年に相当し、ソフトウェアが年を2桁で扱うと問題が生じる可能性がある。^{[ 46 ]}

スペインでは、バッテリー充電モジュールの日付処理バグのため、2025年1月1日にタルゴAVRILクラスの全列車が運行を停止し、乗客が他の車両に移動させられたため、遅延や運休が発生した。 ^{[ 47 ] [ 48 ]}翌日には修正プログラムが適用され、通常の運行が再開された。^{[ 49 ]} 

GNU Core Utilitiesの Rust による書き換えであるコマンドのバグdateにより、 Ubuntu 25.10での自動更新が機能しなくなった。^{[ 50 ] [ 51 ]}uutils

Xbox 360本体のシステム時刻は、2025 年 12 月31 日 23:59 までしか進めることができません。 システムはXbox Live の接続を介して 2026 年以降も進み続けますが^{[ 52 ]} 、 Microsoft ダッシュボード内のソフトウェアの制限により、ユーザーはこの時点以降のシステム日付を設定することはできません^{[ 53 ]}。

一部の旧式システムでは、年を1900年からの1バイトのオフセットとして格納しており、255（8ビット）の範囲で、2155年までの日付を安全に表現できます。しかし、すべてのシステムが符号なしバイトを使用しているわけではありません。一部のシステムは誤って符号付きバイトでコーディングされており、127年の範囲しか許容されないため、ソフトウェアの日付フィールドは2027年以降は不正確になり、予期しない動作を引き起こす可能性があります。ISO 9660 フォーマットを使用して動作するいくつかの光ディスクソフトウェアがこの問題の影響を受けています。^{[ 54 ]}

1970年代後半、データゼネラル社のNovaおよびEclipseシステムにおいて、ワールドコンピュータコーポレーション（信用組合向けアプリケーションを開発）は、16ビットの日付フィールドを持つ日付フォーマットを作成しました。このフォーマットでは、年を表すのに7ビット、月を表すのに4ビット、日を表すのに5ビットが使用されました。これにより、符号なし関数を使用して日付を直接比較することが可能になりました。HP 3000を含む一部のシステムでは、外部コンサルタントによってパッチが開発されているものの、このフォーマットが現在も使用されています。^{[ 55 ]}

Palm OS は、システムクロックやファイル日付 ( PDB フォーマットを参照) など、さまざまなシステム機能に 1970 年エポックの符号付き整数と 1904 年エポックの符号なし整数の両方を使用します。 ^{[ 56 ]}これにより Palm OS は2038 問題の影響を受けやすくなるはずですが、Palm OS は、1904 年を起点とする異なるエポックを使用して年値を格納する 7 ビットのフィールドも使用しており、その結果、最大年は 1904 年から 127 年後の 2031 年になります。^{[ 57 ]}

ネットワークタイムプロトコルには、2038 年問題に関連するオーバーフローの問題があり、これは2038 年ではなく 2036 年 2 月 7 日 06:28:16 UTCに発生します 。NTP で使用される 64 ビットのタイムスタンプは、秒を表す 32 ビット部分と小数秒を表す 32 ビット部分で構成されており、NTP は 2 ³²秒 (136年) ごとにロールオーバーするタイムスケールと、2 ⁻³²秒 (233ピコ秒) の理論上の分解能を持っています。NTP は 1900 年 1 月1 日をエポックとして使用しています。最初のロールオーバーは、UNIX の 2038 年問題より前の 2036 年に発生します。^{[ 5 ] [ 58 ] [ 59 ]}  

同様の問題は、一部のLISP実装にも影響を及ぼしている。^{[ 60 ]}

Apple Macコンピュータは、macOS X Snow Leopardまでは、リアルタイム クロック(RTC) とHFSファイルシステムに、1904 年 1 月1 日 00:00:00 からの秒数を符号なし 32 ビット数として保存していました。2040 年 2 月 6 日 06:28:15  (つまり、エポックから2 ³² − 1秒後) 以降、これは 1904 に戻ります。 ^{[ 5 ] [ 63 ]}さらに、以前はほとんどの Apple コンピュータのデフォルト ファイルシステムであったHFS+も影響を受けます。HFSと HFS+ を置き換えるApple File System は、この問題を解決します。

Apple IIコンピュータで動作する ProDOS は、2 桁の年号のみをサポートしています。Y2K 問題を回避するために、Apple は、年号が 1940 ～ 2039 年を表すことを示す技術メモを発行しました。^{[ 64 ]}このプラットフォームのソフトウェアは、2040 年以降の日付を誤って表示する可能性がありますが、サードパーティが ProDOS とアプリケーション ソフトウェアを更新して4095 年までをサポートする取り組みを進めています。 ^{[ 65 ]}

2042年9月18日、 IBM System/370シリーズのIBMメインフレームとその後継機（現行のIBM Z シリーズを含む）の時刻時計（TODC）がロールオーバーします。^{[ 5 ] [ 66 ]}

^{古いTODCは、2 −12}マイクロ秒（0.244 ns）単位の64ビットカウントとして実装され 、標準ベースは 1900年1月1日（UT）でした。1999年7月に拡張TODCクロックが発表され、クロックが右方向に拡張されました（つまり、拡張ビットは元のビットよりも下位になります）。実際の分解能はモデルによって異なりますが、フォーマットは一貫しており、したがって2 ⁵²マイクロ秒後にロールオーバーします。^{[ 66 ]}

TODC値はユーザーモードプログラムからアクセス可能であり、タイミング計測やイベントの一意のID生成によく使用されます。

IBMは最近のマシンで、タイマーの両端を少なくとも8ビット延長する、より長い（128ビット）ハードウェア形式を定義し実装したが、多くのプログラムは依然として、より長いタイマーのアクセス可能なサブセットとして残る64ビット形式に依存している。

ERPシステムSAP S/4HANAの保守計画スケジューリングでは、2048年1月19日までの終了日しかサポートされていません （ 1980年1月 1日から24,855日 、2 ³¹秒を切り捨てて1日単位に相当）。これは、生産、保守、検査の計画ツールに関係します。^{[ 67 ]}この問題は、9999年までの日付をサポートする新しいアップデートで修正されています。

2桁の年を解析するためのSingle UNIX Specificationによるとstrptime()、「[69, 99]の範囲の値は 1969年から1999年までを指し、[00, 68]の範囲の値は 2000年から2068年までを指す」^{[ 5 ] [ 68 ]}とあり、これは、で解析するとstrptime()、2桁の年「69」は2069年ではなく1969年と解釈されることを意味します。

Nokia Series 40を搭載した一部の（あるいはすべての）Nokia製携帯電話（ Nokia X2-00など）は、2079年12月31日までの日付しかサポートしていない ため、それ以降の日付を表示できません。この問題を回避するには、メイン画面に正しい曜日、日付、月を表示するために、2080年の代わりに1996年、2024年、または2052年（互換性のある閏年）を使用する方法があります。

多くのIBM PCおよびDOSシステムは、1980年以降、多くのRTCと同様に、年を内部的に2桁の値として保存しており、これらは 2079年12月31日以降に繰り越される。

DOSおよびWindowsのファイル日付APIと変換関数（ INT 21h /AH=2Ahなど）は、公式には 2099年12月31日までの日付をサポートしています（基盤となるFATファイルシステムは理論的には2107年までの日付をサポートしていますが）。そのため、DOSベースのオペレーティングシステム、および他の形式をFAT/DOS形式に変換するアプリケーションは、 2100年1月1日以降、予期しない動作を示す可能性があります。

同様に、ニンテンドーDS、ゲームキューブ、ソニーのプレイステーション4では、ユーザーが設定できる日付は2099年までとなっています。ニンテンドーDSの場合、システムは 2099年12月31日以降に時間を進めることはありませんが、ゲームキューブとPS4では、ユーザーがそこまで先の日付と時刻を手動で入力することはできないものの、2100年以降にまで時間を進めることができます。

既存の多くのファイル形式、通信プロトコル、およびアプリケーションインターフェースは、 Unix 日付形式の変種を使用しており、Unixエポック（ 1970年1月1日午前0時UTC）time_tからの秒数を符号なし32ビットバイナリ整数として格納しています。この値は2106年2月7日午前6時28分16秒UTCにロールオーバーします。つまり、現時点では1970年1月1日からの秒数は16進数で表されます。^{[ 5 ]}    FFFFFFFF

この記憶表現の問題は、システム時刻を64ビット符号付き整数値として内部的に保存および操作するプログラムとは無関係である。

FAT ファイルシステムに格納されている日付タイムスタンプは、 1981 年に86-DOS 0.42で初めて導入され、 MS-DOS、PC DOS、DR-DOS などに引き継がれましたが、 2107 年 12 月31 日の終わりにオーバーフローします。^{[ 5 ]}最終更新日時スタンプ(および DELWATCH 2.0 以降ではファイル削除日時スタンプ、DOS 7.0以降ではオプションで最終アクセス日時スタンプと作成日時スタンプも) は、1980 年を基準とした符号なし 7 ビット数 (0～127) で表された年とともにディレクトリ エントリに格納されるため、2108 年以降の日付を示すことはできません。これらの日付を取得するために定義されているAPI 関数は、公式には 2099 年 12 月 31 日までの日付のみをサポートしています 。

これはZIPファイルにも影響します。ZIPファイルは内部的にFATファイルの更新タイムスタンプを使用しているためです。

GPS 日付は週番号と曜日番号で表され、週番号は当初 10ビット値を使用していましたが、最新の GPS ナビゲーション メッセージでは 13 ビット フィールドを使用しています。10 ビット システムでは、1980 年 1 月6 日日曜日(GPSエポック ) から 1024週間 (約 19.6年) ごとにロールオーバーし、13 ビット システムでは 8192週間ごとにロールオーバーします。13 ビット システムでは、2137 年にゼロにロールオーバーします。^{[ 5 ] [ 11 ] [ 12 ]}   

RISC OS は 、日付を1900 年 1 月1 日からの センチ秒 (100 分の 1 秒) 単位で 5 バイト (40 ビット) に格納します。これらのタイムスタンプは内部的に使用され、ファイル メタデータ (ロード アドレスと実行アドレス) に公開されます。^{[ 70 ]} この値は2248 年 6 月 3 日 06:57:57.75 UTCにオーバーフローします 。^{[ 5 ]}

高解像度の時刻計測システムの中には、1970 年 1 月 1 日からのナノ秒を64 ビット符号付き整数でカウントするものがあり、これは2262 年 4 月 11 日23:47:16 UTC にオーバーフローします。Goプログラミング言語のAPI はその一例です。^{[ 71 ]}その他の例としては、Python pandasの Timestamp オブジェクト、^{[ 72 ]}ナノ秒精度に設定されたC++のクラス、^{[ 73 ]}およびQEMUタイマー^{[ 74 ]}などがあります。 UnixNanochrono

Unix 時刻を記録するために長さ 10 文字の文字列を使用するシステムでは、 Unix エポックから 100 億秒後の 2286 年 11 月 20 日 17:46:39 UTC以降の時刻を報告する際に問題が発生する可能 性があります。^{[ 5 ]}

多くの Linux ディストリビューションのデフォルトファイルシステムであるext4では、の下位 2 ビットがフィールドの{a,c,m}time_extra拡張に使用され{a,c,m}time、2038 年の問題は 2446 年に延期されます。^{[ 75 ]} この「追加の」 32 ビットフィールド内では、下位 2 ビットが秒フィールドを符号付き 34 ビット整数に拡張するために使用され、上位 30 ビットがナノ秒のタイムスタンプ精度を提供するために使用されます。したがって、タイムスタンプは 2446 年 5 月までオーバーフローしません。^{[ 76 ]}

数千年という時間スケールで見ると、グレゴリオ暦は天文学的な季節に遅れをとります。これは、地球の自転速度が徐々に遅くなっているため、時間の経過とともに1日の長さがわずかに長くなる一方（潮汐加速と閏秒を参照）、1年の長さは比較的均一に保たれているためです。

19世紀、ジョン・ハーシェル卿は、グレゴリオ暦が4000年ごとに挿入する970日の閏日の代わりに、4000年ごとに969日の閏日を挿入するというグレゴリオ暦の修正案を提案した。^{[ 77 ]}これにより、平均年は365.24225日に短縮される。ハーシェルの提案では、4000年とその倍数が閏年ではなく平年となる。この修正案はその後も何度も提案されているが、公式には採用されていない。^{[ 78 ]}

現在、ほとんどのソフトウェア（Excel、JavaScript、Rなど）は4000年と8000年を閏年として認識していますが（これらは400で割り切れるため）、SASは「4000年ルール」を採用しています。そのため、現在のソフトウェアでは、SASと他のソフトウェア間の日付変換は4000年2月 28日以降に同期がずれてしまいます。^{[ 79 ] [ 80 ]} 

Microsoft Outlook では 、「なし」または「空」のプレースホルダーとして 4501 年 1 月1 日が使用されます。 ^{[ 5 ] [ 81 ] [ 82 ]}

西暦10,000年は、グレゴリオ暦で初めて5桁の年となる。年を4桁までしか表記できないシステムでは、10の累乗となる将来の年や、紀元前10千年紀以前の日付を扱う際に問題が生じるだろう。

UUIDバージョン 7 は 48 ビットのタイムスタンプを使用しており、これは西暦 10889 年にオーバーフローします。^{[ 86 ]}

C# プログラミング言語、または.NETを使用する言語では、DateTime構造体は、グレゴリオ暦のプロレプティック 1年1 月1日の真夜中 (00:00:00.0000000 UTC)からの 10 分の 7 秒 ( 「ティック」として知られる10 ^{−7秒[ 87 ]} ) の数として絶対タイムスタンプを格納します[ ^{88 ] 。}これは、29228 年 9 月 14 日の 02:48:05.4775808 UTCに符号付き 64 ビット整数をオーバーフローします^{[ 5 ] [ 89 ]} 。Microsoftの多くのアプリケーションおよびサービスのタイムキーピング構造は、Power Automateのデータ型^{[ 90 ]}、Azure Cosmos DBのクエリ[ ^{91 ] 、}さまざまなWindows PowerShellコマンドのパラメーター^{[ 92 ]}など、100 ナノ秒の解像度を持ち、これらはすべて同様の問題に直面します。しかし、9999年12月31日23時59分59.9999999UTC以降の日付は「サポート対象外」とみなされ、計算結果が9999年より後の日付になる場合は、時間演算で意図的にエラーが発生します。^{[ 93 ]}      TIMEGETCURRENTTICKSTimeSpan  

Windowsオペレーティングシステムでは、この構造体は、 1601 年 1 月 1 日FILETIMEの午前 1 時 (UTC 00:00:00.0000000) からの 10 分の 1 マイクロ秒数を、符号付き 64 ビット整数として格納します。この値は、 30,828 年 9 月 14 日の 02:48:05 UTCにオーバーフローし、それ以降、Windows は日付を受け付けなくなり、「無効なシステム時刻」エラーを表示します。^{[ 5 ] [ 94 ]}  

同様に、Cosmos DBGETCURRENTTICKSSTATICのコマンドは、 1970 年 1 月1 日の午前 12 時 (UTC 00:00:00.0000000) の Unix エポックからの 100 ナノ秒ティックの数を返します。^{[ 95 ]}これは31197 年 9 月 14 日の 02:48:05 にロールオーバーします。 ^{[ 96 ]}   

年を16ビット値として処理するプログラムは、値が符号付き整数として扱われるか符号なし整数として扱われるかによって、32,768年または65,536年のいずれかを処理する際に問題が発生する可能性があります。

符号付き16ビット整数を使用するシステムでは、32,767年以降の年は負の数として解釈される可能性があり、^{[ 5 ] [ 97 ]} −32,768から始まり、32,768 BCEと表示される可能性があります。符号なし16ビット整数を使用するシステムでは、この問題は、65,536年が0年として表示されるか、^{[ 5 ] [ 98 ]}または65,537年が1年に戻るという形で現れる可能性が高くなります。 

Unix コマンドによって構築された静的ライブラリ アーカイブは、Unix エポックarからの秒数を 10 進数で表した ASCII 文字列としてタイムスタンプを保存します。文字数は 12 文字に制限されます。この値は、Unix エポックから 1 兆秒後の 33,658 年 9 月27 日 01:46:40 UTCにロールオーバーします。 ^{[ 5 ]}  

西暦10万年は、グレゴリオ暦で初めて6桁の年となる。

JavaScriptの Date API は、日付を 1970 年 1 月 1 日からのミリ秒数として格納します。 日付の範囲はエポックから ±100,000,000 日であるため、Date API を使用して JavaScript で書かれたプログラムは、西暦275,760年 9 月 13 日以降の日付を格納することはできません。 ^{[ 5 ] [ 99 ]}  

符号付き 64 ビット整数を使用して Unix 時間を秒単位で保存するシステムは、西暦292,277,026,596年 12 月 4 日日曜日の 15:30:08 UTCまでの日付と時刻を表すことができます。 ^{[ 5 ] [ 100 ] [ 101 ]}しかし、今年は非常に遠い未来（地球、太陽の寿命、さらには宇宙の寿命に関するいくつかの予測をはるかに超えている）であるため、主に理論的な興味の対象、ジョーク、または 2038 年問題のような以前のバージョンは永遠に真に「解決」できないことを示すものとして参照されています。  

また、歴史的な年については、例えば次のような歴史的出来事を扱う際に問題が生じる可能性があります。

• 0年目の問題
• 1000年問題
• 1414年の問題
• 1582年の問題
• 1900年の問題

• ハイゼンバグ– デバッグ中に変化するように見えるソフトウェアのバグ 
• ロング・ナウ財団– アメリカの非営利団体