看到「The perils of transition to 64-bit time_t (gentoo.org)」這篇，原文在「The perils of transition to 64-bit time_t」，Gentoo 的人在討論將 time_t 從 32-bit 換成 64-bit 遇到的困難。
這邊會想把 32-bit time_t 換到 64-bit time_t 的動力是 32-bit 的 time_t 會在 2038 年遇到 integer overflow，這是接下來的十幾年得想辦法的問題。
不過有意思的是 id=41684857 這邊提到了，當初 FreeBSD 在 porting amd64 時 (大約二十年前) 就直接把一堆變數換成 64-bit 了，其中也包括了 time_t，從第一天解決掉相容性的問題：
Every time I see people struggling with this, I am so incredibly glad that I forced the issue for FreeBSD when I did the initial amd64 port. I got to set the fundamental types in the ABI and decided to look forward rather than backward.
The amd64 architecture did have some interesting features that made this much easier than it might have been for other cpu architectures. One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call. In most cases, if you passed a 32 bit time integer to a function expecting a 64 bit time_t, it Just Worked(TM) during the platform bringup. This meant that a lot of the work on the loose ends could be deferred.
We did have some other 64 bit platforms at the time, but they did not have a 64 bit time_t. FreeBSD/amd64 was the first in its family, back in 2003/2004/2005. If I remember correctly, sparc64 migrated to 64 bit time_t.
這算是個 Day 1 沒換就會有技術債包袱的問題 (遲早還是得換)，只是要討論哪種善後的方式是可以接受的。