SoftwareDesign2025年8月号でも取り上げられていたが、2025年になってもまだ2038年問題なのである。
実務上最大の問題はMySQLでのtimestamp型が32bitであることか。だがこれは多くの場合DateTime型へ移行することで問題のないものとなる。
C上での問題も素直にtime_t型を使用していれば通常の問題はないし、strftime()を使っての書式化であれば全く問題など出ない。
世の中の技術者を大いに困らせているのは、time_tをlongでキャストしているバカタレの尻拭いであり、こいつらは意気揚々と「シリアル値の演算で通算秒の差をとれる」とか言いながらせっかくのtime_tをlongでキャストしやがるのです。
そもそもお前はlongがどういうものなのかわかっているのかと小一時間問い詰めたいと20年以上前に語った記憶があるのでまぁそれは置いておいて。

型が時代とともに変化し、同一ソースでは想定外の挙動を起こすことはlongに限らず良くあることではあり、じゃぁどうするのが一番良いのかと人間はいつも考え続けるわけで。
特にC/C++に於いては速度やサイズが重要である場面が多く、型のbit数を把握した上でのコーディングも少なくない。（だからbit演算とかがゴリゴリ出てくる）
とはいえこれらもsizeofやlimits.hやstdint.hあたりをきちんと使えばマジックナンバーを埋め込まずともコーディングは可能なのだから、そうすれば良いだけの話。

で何が言いたかったのかというと、
日時演算は専用関数作って使え
ってことで。問題あってもそこだけ直せば良いのだから。
long32にしたところで、(cur_dt + target_dt) / 2 とかやった時点で2038年を待たずにアウツなんだから、後続のために最低限日時演算処理は別ファイル別関数にしとけ。