So, I probably should explain this, because there’s multiple levels to this joke.
The first level is the 2038 problem, when the “traditional” 32-bit signed time_t rolls over which is going to cause at least as much chaos as Y2K prior to 2000.
The second level is that Solaris has been 64-bit capable since the release of Solaris 7 in 1998, and 64-bit only since Solaris 11 in 2011, so it shouldn’t be a problem anyway.
The third level is the “Solaris Binary Guarantee” which states that a binary compiled for previous versions of Solaris will run unmodified on future versions. However, this means that binaries compiled for Solaris 10 and earlier may be 32-bit, using 32-bit time_t.
So, yes, but no, but yes. Maybe.
EDIT: Alan Coopersmith, who is currently a release manager for Solaris, provides even more details about what’s left in Solaris that still relies on 32-bit time_t: https://hachyderm.io/@alanc/114519310064497360
@[email protected] it's not quite that simple - the Solaris kernel has been 64-bit only since Solaris 11.0, but not the userspace programs - those had been kept mostly 32-bit so they could be used on either a 32-bit or 64-bit kernel, and we started converting them all to 64-bit after the #OracleSolaris 11 release - see https://blogs.oracle.com/solaris/post/moving-oracle-solaris-to-lp64-bit-by-bit and https://blogs.oracle.com/solaris/post/oracle-solaris-114-beta-progress-on-lp64-conversion - we're now up to 98.8% converted and working on finishing the last few we plan to convert and EOL'ing the rest.
@alanc @penguin42 @jpm hey future self, you should have bookmarked this one.
This will be funny to someone in about 975 years.
