All of you Unix heads know about the coming Unix apocalypse. On January 19, 2038, the 32-bit Unix time variable will overflow and Unix will suddenly think it’s December 13, 1901. Except, of course, virtually all extant Unix systems now have time_t defined as a 64 bit integer, which covers us for roughly 20 times the age of the universe. We’re probably safe.
So problem solved? Silent says no, the year 2038 bug is alive and well. Of course, time_t is in no danger of overflowing but there’s still code about that implicitly assumes Unix time is 32 bits. As the example in the post shows, the dependency can be quite subtle. In this case, the villain is a macro that multiplies two 32-bit integers to yield a 64-bit result. It’s used to convert Unix time to a Windows FILETIME value.
Silent has launched a project to hunt down all the places this code is used and provide fixes. Take a look at the post if you’re interesting in helping.
In the mean time, if you want to keep track of things in a graphical way you can use the Emacs function hanoi-unix. It that makes you anxious, try hanoi-unix-64 that shows the same thing but for a 64 bit time_t. Using the Tower of Hanoi puzzle to count down to the end of time is not as whimsical as it seems. According to the legend of the Tower of Brahma, a 64 disk version of the game is being played by priests in the Indian city of Benares. When the puzzle is complete, the legend says, the world will end.