UNIX時間が負の最小範囲にリセットされる2038年の問題に気付いたので、この興味深いトピックについて少し調査することにしました。
現在、(mysql で) データベースの構造を設計していますが、次の 2 つの考慮事項で問題が解決する可能性があると思います。
1) - 時刻データをタイムスタンプ フィールドではなく、bigint (またはそれより大きい) 列に格納します。
2) - アプリケーションに使用するサーバーは 64 ビット OS を使用するため、php 日付関数を使用すると日付が正しく返されます。
タイムスタンプを使用して受け入れようとしているこれらの考慮事項に基づいて、それについてどう思いますか? ありがとう..
MySQLDATETIMEの列には から までの範囲があるため、Y2K38 の問題が心配な場合9999-12-31 23:59:59は、 ではなくそれらを使用することをお勧めします。TIMESTAMP
唯一の利点TIMESTAMPはDATETIME自動化されたタイムゾーン変換ですが、とにかくすべての時間を UTC として保存する傾向があるため、それは問題ではありません。
タイムスタンプを本当に使用したい場合は、2038 年よりもかなり前に、MySQL および C システムをtime_tはるかに範囲の広いものにアップグレードするための協調的な取り組みが行われると確信しています。これは C では固有の型であるため、更新はかなり簡単です。
また、C のフラット ファイルとは異なり、列のメタデータ (どの列にタイムスタンプが含まれているかなど) が簡単に利用できるため、データベース データの移行がはるかに簡単になります。