@nixCraft

Steam needs to get some steam under the 64bit movement too.

@nixCraft Just this week I found that an old source code I wrote in the 1990s used time_t for a 32-Bit time value and thus failed to work when being compiled for 64-Bit Linux. The code didn't even process the time value in any way...

Took me 4 hours to find that bug.

@nixCraft Pardon my ignoreance here, but what happens if I have older version with already compiled apps and update the OS to debian 13 that expects the argument given in time subroutines/API to be 64 bits but my apps are all compiled to provide 32 bit values?

Have they found a trick to have the 64 bit subroutine code figure out t is being called by a 32 bit app and treat the time_t argument as 32 bits? Separate 32 and 54 bit libraries (with 32 bit library subroutines being stubs that take 32 bit argument from old code and convert to 54 before calling the "real" subroutine which expects 64 bits?

Or is this a case where a new install will require recompile of every executable on that machine?

@nixCraft the “isn’t waiting” implies that this bug only appears in a few years in 2038. This isn’t right, as with the year 2000 problem.

Software needs to able to work with dates in the future.