“the committed support for Oracle Solaris until at least 2037”

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

Alan Coopersmith (@[email protected])

@[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.

Hachyderm.io
@jpm stay tuned
@marcel_jomasoft at this point I’m half-expecting Solaris 10 support to get re-extended a few more times to 2037 BUT NO MORE THIS IS THE FINAL EVER END OF SUPPORT DATE
@jpm After 2037, the brakes come off and we see how much air we can get out of our civilisation as it crests the next hill.
@StarkRG That’s right, you get it!
@jpm 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.
@jpm but there's also timestamps embedded in data structures and file formats - like inodes in UFS and login times in utmpx & wtmpx. Since 2038 will be over 30 years past the introduction of ZFS, we're planning to let UFS stop working and have everyone migrate to ZFS by then. Buried in my recent blog is a couple of items about extending the date formats of lastlog, wtmpx, utmpx, & /dev/log (source for syslog): https://blogs.oracle.com/solaris/post/whats-new-in-the-oracle-solaris-11481-cbe-release#lastlog-cbe81
@jpm and yes, despite the binary guarantee, any 32-bit program, no matter what Solaris release it was compiled on or for, cannot run on a system whose clock is past January 2038 - the 32-bit runtime linker/loader will get errors from stat() trying to load dynamically linked libraries like libc (and we haven't supported statically linked binaries since Solaris 10 shipped in 2005).
@alanc Thank you so much for the extra details Alan!
@alanc @jpm It's possible I hit this way way back in the mid 200x; our best Sparc at the startup I was at was I think a 280R, and one day it wouldn't boot far past openprom. - and we couldn't get the Sol 10 install CD to run either. I can't remember what led me there, but my guess was bad time/cmos state; I got it alive again by poking at the Mostek from the prom; which was rather desperate - but since it was the only box with FC disks, and we needed those disks...
@penguin42 @jpm could be - I know our support team has taken a number of calls over the years from systems that couldn't boot because their clock battery died, and after a power outage they were trying to boot with a date randomly set to sometime past 2038.
@alanc @jpm Have you checked if the Solaris kernel stops you setting a date after 2038? My guess is that in this case it was someone who accidentally misset the time (via a syscall?).
@penguin42 @jpm Oh, we know it's possible to set the date past 2038 on a 64-bit kernel - this is used for Y2038 testing. We actually added a check in #OracleSolaris 11.3.8 that if the date has been set before 1970 or past the year 3000 (either by the user or a bad hardware clock) that we issue an error and reset back to 2016 - prior to that the only limits were the ones imposed by the data types.
@alanc @penguin42 Solaris 11 sunset date accidentally spotted
@jpm @penguin42 plenty of time to extend that still, but I plan to be long since retired by then (and most likely dead for centuries), so it’ll be someone else’s problem.

@alanc @penguin42 @jpm hey future self, you should have bookmarked this one.

This will be funny to someone in about 975 years.

@alanc @jpm I have come across UFS still in production use in recent years. Usually the same sites that won't patch because "it might break something".
They get warned, I move on.
@jpm I thought I got it, but turns out it was way deeper than I thought! Thanks for the explanation 
@jpm We have a 32 bit integer overflow coming up.
@alterelefant (that’s the joke, son)
@jpm And non techies still have no idea what this is all about.
@jpm We never get to 2038… it rolls around to 1901-12-14.
@stuartl @jpm Vedic era Hindus also had this problem with long time loops, this is why Indian technical support is the solution...
@jpm oooh only 12 more years until we are free!!
@jpm
I suspect Solaris is 32 bit?
@ddlyh that’s the joke, son. It has been 64-bit native since Solaris 7, released in 1998.
@jpm
Oh, sorry
@ddlyh all good, it’s also been 64-bit only since 2011. There’s a lot of non-obvious layers to the joke.
@jpm To save you some time,
32-bit:
@simonbp There’s more layers to it than just that.
@jpm Imma come out of retirement to fix people's 32-bit shit, like a grizzled old COBOL programmer in the late 1990s.
@elronxenu @jpm I may need to do that too, do you think I'll need to pre-grizzle?
@DrFriendless @jpm If you can do that, it will be looked upon favourably.
@jpm Huh… I thought Sun fixed the 2038 bugs in it's era of Solaris.
@lanodan @jpm unfortunately, no - Sun just added the 64-bit ABI, with 64-bit time_t, but left the 32-bit ABI with 32-bit time_t in place alongside it, along with 32-bit time stamps in a number of existing binary file/data formats, like UFS inodes.
@alanc @jpm Yeah 32-bit time_t filesystems can't really be fixed so you'd have to deprecate them, luckily Solaris made ZFS and it makes sense to use it for at least the root filesystem.
And inside files feels like it's not Sun's job except maybe for the ones they maintained but similarly to filesystems it's not always fixable.
@lanodan @jpm unsurprisingly, our full list of issues looks a lot like the list our #illumos brethren have been gathering at https://github.com/illumos/ipd/tree/master/ipd/0014 (we may exchange notes from time to time).
ipd/ipd/0014 at master · illumos/ipd

illumos Project Discussion. Contribute to illumos/ipd development by creating an account on GitHub.

GitHub
@jpm : I needed this laugh. THANK YOU!!
@jpm 32-bit binaries stop working because they rely on a time_t value that’s too short. #lang_en
@melanie @jpm ditto some file systems, archive file formats (e.g. .lha), database structures and other data structures within binaries.