2023年問題とその周辺の考察
2038年問題って言う、古いサーバーなどが2038年までしか使えない問題があるのですが
2038年問題って、UNIX TIMEの起点を1970年から1990年にずらしたら、2058年問題に出来て誤魔化せるのでは?と。データベースがUNIX TIMEで出来ていたら、コンバートの時手間ですけど
UNIX TIMEでデータを残す時は、そのUNIX TIMEの起点の年を(西暦で)データとして残さないと駄目ですけど
その他、内部LSIの年数も閏年でズレない程度にOSで補正する。例えば、2016年のマイナス(4の倍数の)16年の年数で設定してOSで年を使う時はプラス16年するとか、年数をずらすアルゴリズムにはバリエーションがあると思うのですが
本当は時間合わせのサーバーとマイクロ秒を吐くLSIでOSで時間を管理する方が現実的ですけど
小難しいパソコンの話でした
(´Д`)
2038年問題って、UNIX TIMEの起点を1970年から1990年にずらしたら、2058年問題に出来て誤魔化せるのでは?と。データベースがUNIX TIMEで出来ていたら、コンバートの時手間ですけど
UNIX TIMEでデータを残す時は、そのUNIX TIMEの起点の年を(西暦で)データとして残さないと駄目ですけど
その他、内部LSIの年数も閏年でズレない程度にOSで補正する。例えば、2016年のマイナス(4の倍数の)16年の年数で設定してOSで年を使う時はプラス16年するとか、年数をずらすアルゴリズムにはバリエーションがあると思うのですが
本当は時間合わせのサーバーとマイクロ秒を吐くLSIでOSで時間を管理する方が現実的ですけど
小難しいパソコンの話でした
(´Д`)