glibc はまだ Y2038 対応がデフォルトではない

• 2038-01-09 3:14:07 UTC を過ぎると、32-bit の time_t はオーバーフローする

• Linux カーネルは数年前に内部的に 64-bit へ置き換えており、Alpine は 3.13 から 64-bit time_t に切り替えた

• GNU glibc は 2.34 から 64-bit time_t のサポートを開始したが、そのアプローチは技術的に完全ではない

• musl や他の UNIX C ライブラリ実装では、新しいコードの time_t は常に 64-bit であり、既存の 32-bit コード向けに互換スタブが提供される

→ 時間の経過とともに自動的に Y2038 対応になるようになっている

• Microsoft は msvcrt でさらに一歩進み、デフォルトで 64-bit time_t を使い、_USE_32BIT_TIME_T マクロを使えば従来の 32-bit 関数にアクセスできる

• GNU glibc はちょうど上記 2 つとは逆の方式を取っている

→ 明示的に -D_TIME_BITS=64 を指定しないと使えない

→ いつかこのデフォルトが変わるかもしれないが、今に至るまでまったくそうなっていない

⇨ 同様に、2GiB より大きいファイルを扱うために必要な -D_FILE_OFFSET_BITS=64 も、いまだに明示が必要

→ また 32-bit システムでは -D_TIME_BITS=64 を使ってビルドしてはいけない（つまり Y2038 対応は不可能）

[xguru]

まだ16年ほどありますが、Linux は長期間置き換えられない機器にも多く使われているので..