3 ms·
For open source software, it’s a simple recompile. Most OSS compiles are 64-bit these days, where time_t has always been 64-bit. In the case of compiling a ne
by strenholme 5y ago
For open source software, it’s a simple recompile. Most OSS compiles are 64-bit these days, where time_t has always been 64-bit. In the case of compiling a new 32-bit application, -D_TIME_BITS=64 apparently needs to be a compile time flag.
For binary software, Windows has had a Y2038 compliant proprietary API since Windows NT in the 1990s; most Windows applications use this API so Y2038 is generally not an issue.
The issue only affects a subset of 32-bit binary-only applications where we don’t have the source code any more. Hopefully, any and all applications like that will be decommissioned within the next couple of years.
- rwaksmunski 5y agoI think you misread the root comment, it suggests a new function call that no one will use. Apple made that mistake, then they just switched the size and dealt with the fallout.
- strenholme 5y agoLooks like I lost the context. In terms of the context: The issue is, besides having to rewrite code, it’s not just one function. It’s time_64(), but now we need gmtime_64(), strftime_64(), stat_64(), and so on for any and all functions which use timestamps. The thinking in Linux land is that we won’t have 32-bit applications come 2038 where this matters, because everything will be 64-bit by then.