標準的なC言語の実装では、時刻の表現形式としてUNIX時間《1970年1月1日0時0分0秒（UTC）からの経過秒数》を使用している。これはUNIXの仕様に由来するもので、time_t型という。

C言語の規格を定めた「ISO/IEC 9899:1999」では、time_t型の範囲や精度はいずれも処理系依存としているが、<ref>"The range and precision of times representable in clock_t and time_t are implementation-defined.", ISO/IEC 9899 7.23.1.4</ref>time_t型は、伝統的には符号つき32ビット整数（signed long int型）であり、最大値は (2³¹ - 1) = 2,147,483,647 となる。つまり、2,147,483,647秒までしか計算できない。

このようなAPIの下で作られたアプリケーションでは、1970年1月1日0時0分0秒から2,147,483,647秒を経過した、2038年1月19日3時14分7秒を越えると、この値がオーバーフローし、負と扱われる<ref>時刻の場合、2038年1月19日3時14分7秒の次は、1901年12月13日20時45分52秒となる。</ref>ため、誤作動する可能性が高い。さらに、この仕様は他の多くのプログラミング言語でも採用されているため、それらの言語で作られたアプリケーションも同様に誤作動する可能性が高い。

また、ファイルシステムのext2、ext3、ReiserFSのタイムスタンプも同日付までしか対応していない。

ただし、この期日以前でもプログラムで内部的にこの秒数を超えた時刻データを扱おうとすれば同様のエラーが発生するため、2004年1月11日にはすでにATMの誤作動といったトラブルが発生した（プログラム中に現在時刻を2倍する式があったため、2,147,483,647秒の半分以上経過した時点で誤動作が発生した）。他にも顕在化していないトラブルが今後表面化するという可能性はあり得る。

以下のような理由により、2000年問題より深刻であるという指摘もある。

• 2000年問題はアプリケーションレベルでの修正が可能であったが、この問題は現在普及しているC言語処理系の実装による。
• 「32ビットの符号付二進数の桁あふれ」という理由を理解するには、ある程度の専門知識を必要とするので、一般大衆、経営者、政治家などの理解と関心を得にくい可能性がある。
• 2000年問題のように暦年の変わり目というキリのよいときに地域の標準時に応じて波状的に問題の時刻が世界を巡るのではなく、ごく中途半端な時刻に世界同時に一斉に問題の時刻が訪れるので、もし問題が生じた場合は対応するための人的資源の確保がより困難となる可能性がある。