対策について今回私が見ていたこのシステムではこのTimeStampの最大値がハードコーディングされていました。20年先も運用が続いていたとすると改修が必須になってくると思うのですが、あらゆるところにべた書きされているので修正モジュールが増えて超めんどいですね。いうわけで対策方法を考えてみました。●TimeStamp型を使わないまだ設計段階でMySQLを使うことだけ決まっている状況であれば、TimeStamp型は選択肢から除外してしまいましょう。2038年問題をいちいち考慮しながら設計するよりも他の道を探った方が楽だろうという考え方です。DATETIME型を使う、文字列型にしてyyyy/MM/ddなどのフォーマットを決めるなどです。(何が最適かはケースバイケースですので各々で・・・。)DATETIME型については、TimeStamp型と違いタイムゾーンの概念を持たない型となっているようです。TimeStamp型はそのMySQLが動いたローカル環境のタイムゾーンを基準として、その後UTCに変換して格納するとかなんとかその辺の考慮が入っているみたいです。いうかそもそも「タイムスタンプ」という名前からして、この型はそのレコードの更新日時を自動的にセットすることを想定して作られたもののようで、上記システムのように最終処理日時を入れたり最大値を入れたりって使い方自体がTimeStampの設計思想から外れていた、ということになります。DATETIME型はそんなのないです。グローバルに共通展開しているシステムとかでなければ普通にDATETIMEで良かったんです。●諦めて改修する最もあるべき姿に改修するのであれば、列の定義をDATETIMEなどに変えることです。実際にこの選択肢を選ぶお客様がいたとしたら、それはお金と時間が余っている超優良()企業とかでしょうね。改修インパクトがデカいですし、リグレッションテストもクソめんどいです。お金くれるんならやりますっていう程度です。列定義変更もデータ補正もちょっと考えただけで面倒くさいです。別テーブルとして作成してデータを丸っとお引越しした後に元テーブルを削除する感じになるんでしょうか。この選択肢は無いですね。稼働しちゃってたらどうしたらいいのか実はこの記事を最初に書いたのは1年前のことで、だいぶ時間がたったのですが、1年経って気が付きました。小手先で対応できる応急案は無いんだと。結局おとなしく改修するしかないですね。あと18年も続くシステムなんてそうそう無いでしょうし、大丈夫ですよ、きっと・・・・。コメントをキャンセルメールアドレスが公開されることはありません。*サイト次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。PowerShellで暗号化したパスワードファイルを作成する方法システムエンジニアとしての失敗談その1RECOMMENDこちらの記事も人気です。