It’s good this came up here. I just spent the last week or so going through the MaraDNS code base and fixing all of the little Y2038 issues.
I know, time_t is 64-bit with pretty much any new Linux distro out there, so why are people seeing Y2038 issues? It’s because the Windows 32-bit POSIX compatibility layer handles Y2038 very poorly. Once Y2038 is reached, the POSIX time() call in a 32-bit app fails with a -1. It doesn’t use a rolling timestamp somewhere in 1901 the way 32-bit Linux applications with 32-bit time_t do. It fails hard, returning -1 for every call to time().
Now, it’s true that Microsoft does have proprietary calls for time and date which are Y2038 compliant, and, yes, native Windows32 apps should use those calls instead of the POSIX ones, but in the real world, it’s sometimes a lot easier to, say, just use stat() to get a file’s timestamp instead of having to use CreateFile() followed by GetFileTime().
This is why a lot of Windows apps are still seeing Y2038 issues.
In terms of Linux apps, the Y2038 stuff is mainly seen in old 32-bit binary only apps. Since that stuff is mainly games, where an inaccurate datestamp isn’t a serious issue, I think we will see emulation libraries which give old games a synthetic time and date so they aren’t outside of the Y2038 window. New apps will use a 64-bit time_t even if compiled as a 32-bit binary.
I know, time_t is 64-bit with pretty much any new Linux distro out there, so why are people seeing Y2038 issues? It’s because the Windows 32-bit POSIX compatibility layer handles Y2038 very poorly. Once Y2038 is reached, the POSIX time() call in a 32-bit app fails with a -1. It doesn’t use a rolling timestamp somewhere in 1901 the way 32-bit Linux applications with 32-bit time_t do. It fails hard, returning -1 for every call to time().
Now, it’s true that Microsoft does have proprietary calls for time and date which are Y2038 compliant, and, yes, native Windows32 apps should use those calls instead of the POSIX ones, but in the real world, it’s sometimes a lot easier to, say, just use stat() to get a file’s timestamp instead of having to use CreateFile() followed by GetFileTime().
This is why a lot of Windows apps are still seeing Y2038 issues.
In terms of Linux apps, the Y2038 stuff is mainly seen in old 32-bit binary only apps. Since that stuff is mainly games, where an inaccurate datestamp isn’t a serious issue, I think we will see emulation libraries which give old games a synthetic time and date so they aren’t outside of the Y2038 window. New apps will use a 64-bit time_t even if compiled as a 32-bit binary.