32ビット組み込みLinux（ARMLinux）のCコードで時間を処理して、2038年1月19日（03:14:07 UTC）にコードが正しく動作することを保証する適切な方法は何ですか（符号付き32ビットtime_tオーバーフロー）？私が使用しなければならないシステムでtime_tが32ビットで署名されているとすれば、どのような代替案がありますか？組み込みLinux（32ビット）用の2038年ソリューション？
グーグルのかなりの量が、実用的な使用の何も明らかにしていません。誰もがそれまでに64ビットOSを使用することを想定しているようですが、これは組み込みシステムには当てはまりません。
私が使用する必要があるシステムでは、はlongと定義されています。おそらく、64ビット時間のカーネル機能がないということです。 uClibcのバージョンは0.9.29です。
私はこの問題を抱えている唯一の人だとは思っていません。私は車輪を再構築したくありません。
銀色の弾丸、トリック、または巧妙な解決策はありません。 time_tが64ビットのオペレーティングシステムを使用するか、またはtime_tとそれに依存するOS機能（ファイルシステム、タイマー、ネットワークの半分などを含む）を使用しないでください。また、今後20年間でソフトウェアを更新する予定です。
32ビットマシン上に64ビットのtime_tを持つ少なくとも2つのUNIX系システムがあります：OpenBSDとNetBSD。 OpenBSDはその背後にある理由を説明するいくつかの講演を行った：http://www.openbsd.org/papers/eurobsdcon_2013_time_t/index.html
私はこれを答えとしてマークしました。なぜなら、私たちの最終的な決定は、今のところ32ビット時間で生きて、後で問題を心配することだったからです。 IMOの素晴らしい解決策ではありませんが、私が取り組んでいるコンポーネントだけが影響を受けるわけではありません。 –
時間変換ルーチンは、タイムスタンプが特定の値以下の場合、「単純に」2038-01-19：03：14：07ZをUnixエポック時間のベースとして使用する必要があります。
I.e.システムが2010-01-01で生産性を上げている場合は、オーバーフローしていないタイムスタンプは1262300400（その日付のUnixエポックタイム）未満であるとみなすことはできません。
タイムスタンプがより低い場合は、オーバーフローし、2038-01-19：03：14：07Zを基準時刻として使用することを検討してください。比較も考慮する必要があります。
清潔な解決策ではありませんが、中程度の努力で解決できます。 64ビットタイムスタンプへの切り替えを改善しました（64ビットシステムを絶対に必要としない、btw）。
組み込みシステムのABIは、longを32ビットと定義しています。
time_tタイプに署名する必要はありません。あなたはおそらくそれをunsigned longにして、余分な68年間の静けさをあなた自身とあなたの子孫に買ってもらえますか？これを変更するには、カーネルを再コンパイルする必要があります.Cライブラリとtime_tを使用するすべてのプログラムとライブラリは...心の弱いものではありません！ long longと定義することもできますが、これは多くの構造レイアウトを変更し、さらに困難になります。
私はこれは良い質問であると同意するが、それはあまりにも広すぎるかもしれない。 LKMLを検索しましたか、リクエストを投稿しましたか？ – Olaf
@Olaf：私は、Linuxカーネルの作者が何をしているのかを見てきましたが、それはすべて64ビットシステムを中心に展開しています。私はこの質問が広すぎるとは思わない。率直に言って、私は、とにかくそれをやり遂げるさまざまな方法があるとは思っていません。答えは、おそらく「組み込みシステムのための現在の普遍的な解決策はありません。 –
今から20年以上です –